On 01/31/2013 12:43 PM, Ali Çehreli wrote:
On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
> On 1/31/13, Ali Çehreli<acehr...@yahoo.com> wrote:
>> For the same reason, if it is really an Error that has been thrown,
even
>> the destructors are not called during stack unwinding.
>
> Where are you extracting this information from?
I hope I haven't spread wrong information. I "learned" this from the
discussions on this forum. Perhaps it was merely an idea and I remember
it as truth.
Others, is what I said correct? Why do I think that way? :)
I tested this with dmd. struct destructors do get called during stack
unwinding.
However, a relevant quote:
http://dlang.org/phobos/object.html#.Exception
"In principle, only thrown objects derived from [Exception] are safe to
catch inside a catch block. Thrown objects not derived from Exception
represent runtime errors that should not be caught, as certain runtime
guarantees may not hold, making it unsafe to continue program execution."
TDPL talks about what happens (and does not happen) when a function in
declared as nothrow. It also talks about why Throwable should not be
caught. It doesn't say the same exact things about Error but the book
draws a clear distinction between the Exception sub-hierarchy and the
other exception classes.
There is great information in Chapter 9 of TDPL but they are quite large
to type here. Especially sections 9.2 and 9.4 are relevant.
The following are my thoughts...
Here is the logic behind why the destructors must not be executed when
the thrown exception is an Error. AssertError is an Error, indicating
that the program state is wrong. When the program state is wrong, there
is no guarantee that any further operation in the program can safely be
executed.
Assume that the AssertError is coming from the invariant block of a
struct (or assume that any other assert about the state of an object has
failed). In that case the object is in a bad state. Can the destructor
be called on that object? Should it be? What can we expect to happen?
Ali
