DIP33: A standard exception hierarchy

Jonathan M Davis jmdavisProg at gmx.com
Mon Apr 1 13:30:12 PDT 2013


On Monday, April 01, 2013 13:23:49 monarch_dodra wrote:
> On Monday, 1 April 2013 at 11:08:16 UTC, Lars T. Kyllingstad
> 
> wrote:
> > It's time to clean up this mess.
> > 
> > http://wiki.dlang.org/DIP33
> 
> A quick comment about your "Error" section. You say:
> 
> "In general, Errors should not be caught, primarily because they
> indicate that the program logic is compromised, and that the
> program may therefore be in an invalid state from which there is
> no recovery".
> 
> It is actually much worst than that: errors bypass the entire
> exception handling mechanism, blasting through code that would
> handle destructors, and even flying through functions that are
> nothrow. They don't just indicate a "potential" invalid state,
> they actually *put* the program in an invalid state, from which
> there is no recovery.
> 
> That is the main mechanical difference between an "error" and an
> "exception", it is not just a philosophical "logic vs runtime".
> 
> --------
> 
> Under this situation, I'm wondering how the "OutOfMemory" is
> dealt with (you don't explain).

It's not an Exception, so no clean-up is guaranteed. _Any_ Throwable which is 
not an Exception risks no clean-up being done. Error really has nothing to do 
with it beyond the fact that it's not an Exception.

Now, the reality of the matter is that the current implementation _does_ 
generally do clean-up when non-Exceptions are thrown (the major exception 
being code dealing with nothrow functions IIRC), but according to Walter, 
there's no guarantee that that's the case (and I'm not sure that he's 
particularly happy that any clean-up happens at all for non-Exceptions like it 
does right now).

- Jonathan M Davis


More information about the Digitalmars-d mailing list