runtime hook for Crash on Error

[Don Clugston]

On 01/06/12 12:26, Walter Bright wrote:
> 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.

This argument seems to be:

1. There exist cases where you cannot know why the assert failed.
2. Therefore you never know why an assert failed.
3. Therefore it is not safe to unwind the stack from a nothrow function.

Spot the fallacies.

The fallacy in moving from 2 to 3 is more serious than the one from 1 to 
2: this argument is not in any way dependent on the assert occuring in a 
nothrow function. Rather, it's an argument for not having AssertError at 
all.