Chaining exceptions

Sean Kelly sean at invisibleduck.org
Wed Nov 18 18:19:36 PST 2009


Andrei Alexandrescu Wrote:

> Sean Kelly wrote:
> > 
> > When a dozen holes appear in a dike, I'm not sure it matters which
> > one you try to plug first :-)  Unless there's some way to start with
> > the biggest one, I suppose.  Seems like with the suggested model, the
> > correct approach may be to always catch Exception and walk the whole
> > chain to figure out what to do.  But that sounds awfully close to
> > C-style error handling.
> 
> Well I'm not sure about the metaphor. What I can tell from my code is 
> that exceptions are often contingent one upon another (not parallel and 
> independent). A typical example: writing to a file fails, but then 
> closing it also fails and possibly attempting to remove the partial file 
> off disk also fails. In that case, the important message is that the 
> file couldn't be written to; the rest is aftermath. If the doctor says 
> "You have a liver problem, which causes your nails to have a distinctive 
> shape" you don't mind the nails as much as the liver.

Upon reflection, I'm inclined to agree.  This is pretty much a nonexistent case for me anyway (my experience with C++ has me following the "no exceptions from dtors ever" mantra for the most part), so it's difficult to come up with counterexamples.  I also like that your chaining method represents a timeline of what happened, with the most likely cause of the whole mess at the head of the list.
 
> There's also the opposite flow, for example an exception in some 
> validation prevents a database update. But I don't think code regularly 
> does essential work in destructors, finally blocks, and scope 
> statements. The essential work is done on the straight path, and the 
> important error is happening on the straight path.

Yeah, I think you're right.



More information about the Digitalmars-d mailing list