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 <[email protected]> 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
