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