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