I want this.
I want this.
This is what our good old friend the core dump is for. Load the core dump in GDB and there you are.
I'd argue that on windows it's even easier. You can create a symbol server to store all the debugging info (the PDB files) and the debugger can download the correct symbols for that particular compiled version.
The PDB format supports having an arbitrary commands added to procure each source file. You can connect this up to your version control system so that not only do you have the stack and symbols, you can actually browse around the source code of whatever version of the code actually crashed just as if it had crashed locally.
On linux you have to work out a system for archiving your symbols and getting them for the correct version of your software yourself, but the effort is certainly worth it.
We have a system to generate HTML reports each day by grouping crash dumps by the functions near the top of the stack (if the top 5 functions are the same, it's considered the same crash), so each day we can see what the most important crash is.
3. You enter some code and hit proceed
4. The app continues like nothing happened
A short (<3min) video demoing the same: http://vimeo.com/27850933Whereas, generally with Common Lisp, I can trap the condition, fix the problem, and keep running.
I know what languages I'd consider starting grounds for 100% uptime systems (not 5 9s), and languages that segfault and die as part of their usual crash hangling are not among them.
(Erlang, Lisp, and Smalltalk would be my shortlist)
On linux the situation is a little harder. I am not aware of edit and continue on that platform.
Any kind of crash is catchable. For example, we get minidumps of our windows software uploaded by the crashing process by catching any kind of crash that is possible, and handling it.
However, I would argue that you want to crash and dump a core as fast as possible when something unanticipated is happening. Process death should not be a problem in a well designed system!