RE: [boost] Re: Virtual inheritance in exception hierarchies

From: Alan.Griffiths_at_[hidden]
Date: 2003-09-05 03:07:27

> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: 04 September 2003 18:25
> 
> Not at all.  std::exception& is a good fallback for error reporting
> *before* catch(...) reports "unknown exception" because you may be
> able to get something from the what() string.  Further, if you follow
> Peter D's advice of using what() for a key into a table of messages,
> you almost always want to catch(std::exception&).

I'm not very worried about a "fallback" like that falling through to catch
(...).  What worries me is client code that *omits* the catch (...) for the
reasons that have been raised in past discussions.

"catch (std::exception& x)" can only be a reliable backstop if there is an
expectation that all exceptions will be specialisations of std::exception.
I've never worked on a project of any size where this was even remotely
plausible.

Even on my current project (very small - 1 person for a couple of months)
exceptions come in the following forms:

  /1/ specialisations of: std::exception

  /2/ pointers to CException

  /3/ specialisations of: _com_error

  /4/ pointers to FOOLibrary::Exception

All (except the first) are caught in the modules that invoke the subsystems
that create these and "wrapped" into the "barlibrary::exception" hierarchy
(which, incidentally, specialises std::exception).  I think this is the
"normal" pattern: translating error reports at subsystem/package boundaries
(I also translate other reporting mechanisms - like return codes - in the
same way).

Now, AFAICS the only thing that will ever throw barlibrary::exceptions is
the library that I'm creating.  And it is entirely implausible that there
will be code that throws these exceptions that simultaniously classifies
them in another hierarchy.

The same is true of the majority of boost libraries: there is no expectation
of the sort of chimeric implementation that your example illustrates.

PS

I am beginning to see an appeal to the idea of using MI rather than wrapping
- if only I could do:

namespace barlibary 
{
    class foobar : public exception, public *FOOLibrary::Exception { ... }
}

-- 
Alan Griffiths
http:://www.octopull.demon.co.uk/
------------------------------------------------------------------------
For more information about Barclays Capital, please
visit our web site at http://www.barcap.com.
Internet communications are not secure and therefore the Barclays 
Group does not accept legal responsibility for the contents of this 
message.  Although the Barclays Group operates anti-virus programmes, 
it does not accept responsibility for any damage whatsoever that is 
caused by viruses being passed.  Any views or opinions presented are 
solely those of the author and do not necessarily represent those of the 
Barclays Group.  Replies to this email may be monitored by the Barclays 
Group for operational or business reasons.
------------------------------------------------------------------------