runtime hook for Crash on Error

[Andrei Alexandrescu]

On 5/31/12 6:16 PM, Walter Bright wrote:
> On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
>> On 31.05.2012 13:06, deadalnix wrote:
>>> This is called failing gracefully. And this highly recommended, and you
>>> KNOW that the system will fail at some point.
>>
>> Exactly. + The point I tried to argue but it was apparently lost:
>> doing stack unwinding and cleanup on most Errors (some Errors like stack
>> overflow might not recoverable) is the best thing to do.
>
> This is all based on the assumption that the program is still in a valid
> state after an assert fail, and so any code executed after that and the
> data it relies on is in a workable state.
>
> This is a completely wrong assumption.
>
> It might be ok if the program is not critical and has no control over
> important things like delivering insulin, executing million dollar
> trades, or adjusting the coolant levels in a nuclear reactor.
>
> If the code controls anything that matters, then it is not the best
> thing to do, not at all.
>
> The right thing to do is to take the shortest path to stopping the
> program. A critical system would be monitoring those programs, and will
> restart them if they so fail, or will engage the backup system.
>
> [When I worked on flight critical airplane systems, the only acceptable
> response for a self-detected fault was to IMMEDIATELY stop the system,
> physically DISENGAGE it from the flight controls, and inform the pilot.]

I wonder how we could work into this enthusiasm fixing bugs created by 
comparing enumerated values of distinct types...

It did happen in a program of mine to confuse a UserID with a CityID. If 
the corrupt CityID would be subsequently entered into the navigation 
system of an airplane, it would lead the airplane on the wrong path.


Andrei