[Exceptional C++ Style] Fw: Item 11: Try and Catch Me

Kevlin Henney kevlin at curbralan.com
Wed Dec 1 10:26:04 EST 2004


In message <057d01c4d7a0$6be02f50$1801a8c0 at evaluategroup.local>, Adrian 
Fagg <adrianf at evaluategroup.com> writes
>
>For more direct remedies, I would go for a callback mechanism rather than an
>exception handler, as this allows for continuity (with a little care to
>avoid infinite loops, obviously).

Definitely. The great overlooked solution, in fact. I implemented this 
in a framework for a customer earlier this year. It was one of the few 
cases that I had a catch(...) that could in principle swallow the 
exception: the framework was a driver for arbitrary plug-ins, so falling 
over would have been considered poor quality-of-failure. It was possible 
to register handlers for various events, including exceptions that arose 
from lower levels, the plug-in or wherever, but in principle it was also 
possible for the handlers to screw up, so there had to be some limit. In 
the case of the driver function it was better to be silent and there 
than noisy and not. It is a not a scenario that, to the best of my 
knowledge, has ever been called upon, but it did need to be addressed as 
a possibility, no matter how remote.

>This item is mostly concerned with the fact that code has to be written in
>an exception friendly fashion, rather than focussing on what you can do with
>the exception when you catch it. Generally if an operation fails, the most
>you can do is provide information on what went wrong and ensure that state
>is as it should be (i.e. transactions rolled back etc.).
>After that, recovery depends very much on the domain. Sometimes it might be
>best to blindly try again in the hopes that it works this time e.g. when
>applying brakes in response to the brake pedal having been pressed.;-)
>Alternatively, rebooting and hoping it works next time might be all you can
>do when something goes wrong with your Mars robot.

There's that context dependency of quality-of-failure again :-)

>Opening the dialog is probably due to
>pushing a button and a response 'We are experiencing technical difficulties
>and cannot open your dialog at this time.' wouldn't be much help to anyone.

Although it might salve someone's conscience, ineffective as it is in 
any other way.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________



More information about the Effective-cpp mailing list