runtime hook for Crash on Error

[Dmitry Olshansky]

On 05.06.2012 15:57, Don Clugston wrote:
> 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.

Finally voice of reason. My prayers must have touched somebody up above...

>
> 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.
>

Exactly, hence the whole idea about SEH in the OS.

> 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.


-- 
Dmitry Olshansky