On 30/05/12 12:59, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to be),
then what does it matter? Something fatal occured in your program, so it
terminates. Because it's an Error, you can get a stack trace and report
something before the program actually terminates, but continuing
execution after an Error is considered to be truly _bad_ idea, so in
general, why does it matter whether scope statements, finally blocks, or
destructors get executed? It's only rarer cases where you're trying to do
something like create a unit test framework on top of assert that you
would need to catch an Error, and that's questionable enough as it is. In
normal program execution, an error is fatal, so cleanup is irrelevant and
even potentially dangerous, because your program is already in an invalid
state.
That's true for things like segfaults, but in the case of an
AssertError, there's no reason to believe that cleanup would cause any
damage.
In fact, generally, the point of an AssertError is to prevent the
program from entering an invalid state.
An assertion failure really isn't all that different from a segfault. By
definition, if an assertion fails, the program is an invalid state, because the
whole point of the assertion is to guarantee something about the program's
state.
There's a big difference. A segfault is a machine error. The integrity
of the machine model has been violated, and the machine is in an
out-of-control state. In particular, the stack may be corrupted, so
stack unwinding may not be successful.
But, in an assert error, the machine is completely intact; the error is
at a higher level, which does not interfere with stack unwinding.
Damage is possible only if you've written your destructors/finally code
extremely poorly. Note that, unlike C++, it's OK to throw a new Error or
Exception from inside a destructor.
But with (say) a stack overflow, you don't necessarily know what code is
being executed. It could do anything.
Now, if a segfault occurs (particularly if it's caused by something
other than a null pointer), the program is likely to be in a _worse_ state,
but it's in an invalid state in either case. In neither case does it make any
sense to try and recover, and in both cases, there's a definite risk in
executing any further code - including cleanup code.
Yes, the segfault is
probably worse but not necessarily all that much worse. A logic error can be
just as insidious to the state of a program as memory corruption, depending on
what it is.
I'm surprised by your response, I didn't think this was controversial.
We could just as easily have said assert() throws an AssertException.
(Or have two kinds of assert, one which is an Error and the other merely
an Exception).
