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

[Adrian Fagg]

> -----Original Message-----
> From: effective-cpp-bounces at accu.org
> [mailto:effective-cpp-bounces at accu.org]On Behalf Of SamS at helpit.com
> Sent: 30 November 2004 17:26

> > Right. An example of the third is when a class's implementation
> > catches a basic exception (e.g., bad_alloc) to one with higher-level
> > semantics that makes sense in the context of the class (e.g.,
> > CannotOpenDialog).
> >
> This is where it may not be so clear cut. A client may be
> able to release a
> pre-allocated chunk of memory in response to a bad_alloc
> exception and try
> the function again, but once the function has decided to
> translate bad_alloc
> into CannotOpenDialog, the cause of the error is either lost
> or at best
> masked and obtainable through some query mechanism.

On a point of order, this wouldn't be a feasible strategy in the face of
most modern systems.

> To continue with your example, consider the following
> scenario. The part of
> the code that knows how to handle bad_alloc by releasing a
> pre-allocated
> chunk of memory may be higher up the call stack. So, either
> this part of
> code has to catch CannotOpenDialog exceptions as well and
> query them to find
> out if they were caused by a memory shortage, or the
> CannotOpenDialog has to
> be translated back into something like bad_alloc which is
> also a painful
> thought. Either way, the cause of the exception gets masked
> an may indeed
> become more difficult to handle instead of easier.

CannotOpenDialog could have a cause field (or chain), so the client can
query it for bad_alloc.
This is usually not a great idea though.

> The fundamental difference between the two types of
> exceptions, bad_alloc
> and CannotOpenDialog, is that the first indicates the _cause_ of the
> failure, whereas the latter indicates _activity_ that failed.
> The _cause_
> type of exceptions may be easier to handle than the _activity_ type
> exceptions. Any one ideas on this?

I'm not completely convinced. Encapsulation usually requires that the
'cause' is dealt with on the inside or that it is merely reported as the
reason for failure.
In terms of an application with a UI, this usually is best handed all the
way out to the user.
Errors such as 'no disk in drive' can't easily be remedied purely in
software.

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).

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.

Generally, though, translation of exceptions only makes sense at a level
where the context of the original exception makes it valueless to the
caller. So you wouldn't want to translate anything to CannotOpenDialog until
you were past the point at which you were opening the dialog. For most
applications, you wouldn't be there. 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.

Sorry, rambling again.

Regards,

Adrian

Work: mailto:adrianf at evaluategroup.com
Home: mailto:adrian.fagg at ntlworld.com

Pretty pictures: http://homepage.ntlworld.com/rbyadf/