[your code here]

Maxim Fomin maxim at maxim-fomin.ru
Thu Jan 31 13:59:05 PST 2013


On Thursday, 31 January 2013 at 20:43:37 UTC, Ali Çehreli wrote:
> On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
> > On 1/31/13, Ali Çehreli<acehreli at 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? :)
>
> Ali

There is not much information about this topic, but I believe 
there are two separate issues here (technical and practical):

1) Errors can behave not always like exceptions. For example, 
most errors (which are not thrown directly) are generated by D 
features: final switch throws SwitchError, notorious activity 
inside class dtors which calls GC causes 
InvalidMemoryOperationError, etc. These are typically called  as 
OnXXError functions and are in druntime 
(https://github.com/D-Programming-Language/druntime/blob/master/src/core/exception.d). 
Theoretically this functions may just terminate application 
without throwing exception, so point here is that even trying to 
catch Error can be useless. However if Error is thrown by D 
exception mechanism, I think you can handle it just like other 
Throwables.

2) Although you can (sometimes) catch Error, state of the program 
is in unpredictable condition. These conditions may depend on 
type of error and other factors.


More information about the Digitalmars-d mailing list