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.
