Exception/Error division in D

Don Clugston dac at nospam.com
Wed May 30 08:29:30 PDT 2012


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



More information about the Digitalmars-d mailing list