runtime hook for Crash on Error

[Don Clugston]

On 05/06/12 09:07, Jonathan M Davis wrote:
> On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
>> On 04/06/12 21:29, Steven Schveighoffer wrote:
>>> On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston<dac at nospam.com>  wrote:
>>>> 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.
>>>
>>> I'm not sure that is the issue here at all. What I see is that the
>>> unwinding of the stack is optional, based on the assumption that there's
>>> no "right" answer.
>>>
>>> However, there is an underlying driver for not unwinding the stack --
>>> nothrow. If nothrow results in the compiler optimizing out whatever
>>> hooks a function needs to properly unwind itself (my limited
>>> understanding is that this helps performance), then there *is no
>>> choice*, you can't properly unwind the stack.
>>>
>>> -Steve
>>
>> No, this whole issue started because the compiler currently does do
>> unwinding whenever it can. And Walter claimed that's a bug, and it
>> should be explicitly disabled.
>>
>> It is, in my view, an absurd position. AFAIK not a single argument has
>> been presented in favour of it. All arguments have been about "you
>> should never unwind Errors".
>
> It's quite clear that we cannot completely, correctly unwind the stack in the
> face of Errors.

Well that's a motherhood statement. Obviously in the face of extreme 
memory corruption you can't guarantee *any* code is valid.
The *main* reason why stack unwinding would not be possible is if 
nothrow intentionally omits stack unwinding code.

> As such, no one should be relying on stack unwinding when an
> Error is thrown.

This conclusion DOES NOT FOLLOW. And I am getting so sick of the number 
of times this fallacy has been repeated in this thread.

These kinds of generalizations are completely invalid in a systems 
programming language.

> Regardless, I think that there are a number of people in this thread who are
> mistaken in how recoverable they think Errors and/or segfaults are, and they
> seem to be the ones pushing the hardest for full stack unwinding on the theory
> that they could somehow ensure safe recovery and a clean shutdown when an
> Error occurs, which is almost never possible, and certainly isn't possible in
> the general case.
>
> - Jonathan M Davis

Well I'm pushing it because I implemented it (on Windows).

I'm less knowledgeable about what happens on other systems, but know 
that on Windows, the whole system is far, far more robust than most 
people on this thread seem to think.

I can't see *any* problem with executing catch(Error) clauses. I cannot 
envisage a situation where that can cause a problem. I really cannot.

And catch(Exception) clauses won't be run, because of the exception 
chaining scheme we have implemented.

The only difficult case is 'finally' clauses, which may be expecting an 
Exception.