runtime hook for Crash on Error

[Jonathan M Davis]

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. As such, no one should be relying on stack unwinding when an 
Error is thrown. The implementation may manage it in some cases, but it's 
going to be unreliable in the general case regardless of how desirable it may 
or may not be.

The question is whether it's better to skip stack undwinding entirely when an 
Error is thrown. There are definitely cases where that would be better, since 
running cleanup code could just make things worse, corrupting even more stuff 
(including files and the like which may persist passed the termination of the 
program). On the other hand, there's a lot of cleanup code which would execute 
just fine when most Errors are thrown, and not running cleanup code causes its 
own set of problems. There's no way for the program to know which of the two 
situations that it's in when an Error is thrown. So, we have to pick one or 
the other.

I really don't know which is the better way to go. I'm very tempted to go with 
Walter on this one, since it would avoid making the worst case scenario worse, 
and if you have cleanup which _must_ be done, you're going to have to find a 
different way to handle it, because even perfect stack unwinding won't protect 
you from everything (e.g. power loss killing the computer). But arguably, the 
general case is cleaner if we do as much stack unwinding as we can.

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