On Thursday, 3 October 2013 at 08:02:17 UTC, Max Samukha wrote:
On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright
wrote:
Right. A null pointer dereference is a logic bug in your
program, and hence the program needs to stop immediately, not
execute "cleanup" code.
If there's one notion I'd like to terminate with prejudice,
it's the notion that a running program can "recover" from bugs
in itself.
That famous prejudice of yours :). As always, it depends. The
application can't "recover" but it can give the user an
opportunity to (partially) recover his work. For example, I
appreciated the fact that Cubase/Nuendo often continued
execution after a poorly debugged in-process plugin segfaulted.
I do not know exactly what cleanup procedure the application
executed on the inconsistent state but most of the time I was
able to recover it completely.
This.
I agree that in a purist sense, a broken program is broken, end
of. However, in the real world it's a balance of risk.
