runtime hook for Crash on Error

[Walter Bright]

On 6/1/2012 1:48 AM, Dmitry Olshansky wrote:
> On 01.06.2012 5:16, 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.
>
> To be frank a "completely wrong assumption" is flat-out exaggeration. The only
> problem that can make it "completely wrong" is memory corruption. Others just
> depend on specifics of system, e.g. wrong arithmetic in medical software ==
> critical, arithmetic bug in "refracted light color component" in say 3-D game is
> no problem, just log it and recover. Or better - save game and then crash
> gracefully.

Except that you do not know why the arithmetic turned out wrong - it could be 
the result of memory corruption.


> @safe D code should be enough to avoid memory corruption. So in @safe D code
> AssertError is not memory corruption. Being able to do some logging and
> gracefull teardown in this case would be awesome. I mean an OPTION to do so.

You do have the option of catching assert errors in D, but such cannot be 
represented as a correct or robust way of doing things.

> Wrong values don't always corrupt "the whole program" state.

Right, but since you cannot know how those values got corrupt, you cannot know 
that the rest of the program is in a valid state. In fact, you reliably know 
nothing about the state of a program after an assert fail.

> It's too conservative point of view. It is a reasonable DEFAULT, not a rule.

It's a rule. Break it at your peril :-) I am not going to pretend that it is a 
reasonable thing to do to try and keep running the program.


> (just look at all these PHP websites, I'd love them to crash on critical errors
> yet they still crawl after cascade failures with their DBs, LOL)

Other people writing crappy, unreliable software is no excuse for us.


> BTW OutOfMemory is not an Error. To me it's like can't open file. Yeah, it could
> be critical if your app depends on this articular file but not in general.

OOM is a special case. I agree that that isn't a corruption error. But I've 
almost never seen a program that could recover from OOM, even if it was designed 
to. (For one reason, the recovery logic for such is almost never tested, and so 
when it is tripped, it fails.)


> I don't agree that OutOfMemory is critical:
> --> make it an exception ?

The reason it is made non-recoverable is so that pure functions can do something 
useful.