runtime hook for Crash on Error

[Walter Bright]

On 6/1/2012 1:06 PM, Dmitry Olshansky wrote:
> Indeed it's quite bad to assume both extremes - either "oh, my god everything is
> corrupted" or "blah, whatever, keep going". I thought D was trying to hold keep
> reasonable compromises where possible.

D has a lot of bias towards being able to mechanically guarantee as much as 
possible, with, of course, allowing the programmer to circumvent these if he so 
desires.

For example, you can XOR pointers in D.

But if I were your program manager, you'd need an extraordinary justification to 
allow such a practice.

My strongly held opinion on how to write reliable software is based on decades 
of experience by others in the aviation business on how to do it. And the proof 
that this works is obvious.

It's also obvious to me that the designers of the Deep Water Horizon rig and the 
Fukishima plant did not follow these principles, and a heavy price was paid.

D isn't going to make anyone follow these principles - but it is going to make 
it more difficult to violate them. I believe D should be promoting, baked into 
the design of the language, proven successful best practices.

In programming courses and curriculum I've seen, very little attention is paid 
to this, and programmers are left to discover it the hard way.


> By the way memory corruption is checkable. And even recoverable, one just needs
> to have certain precautions like adding checksums or better yet ECC codes to
> _every_ important data structure (including of course stack security hashes).
> Seems very useful for compiler generated code with '-debug' switch. It even can
> ask GC to recheck ECC on every GC datastructure. Do that memory check on each
> throw of error dunno. Trust me to do the thing manually I dunno. Provide some
> options, damn it.
>
> For all I care the program is flawless it's cosmic rays that are funky in this
> area.
>
> Certain compilers by the way already do something like that on each stack
> entry/leave in debug mode (stack hash sums).
>
> P.S. Trying to pour more and more of "generally impossible" "can't do this",
> "can't do that" and ya-da-ya-da doesn't help solving problems.

It doesn't even have to be memory corruption that puts your program in an 
invalid state where it cannot reliably continue. The assert would have detected 
a logic bug, and the invalid state of the program is not at all necessarily 
memory corruption. Invalid does not imply corruption, though corruption does 
imply invalid.