[boost] Re: Virtual inheritance in exception hierarchies

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-05 11:44:14

Alan.Griffiths_at_[hidden] writes:

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

Other people have other worries.

> "catch (std::exception& x)" can only be a reliable backstop if there is an
> expectation that all exceptions will be specialisations of
> std::exception.

"Reliable" isn't the only concern.  When you get an exception you
weren't expecting, *any message at all* is better than no message,
for diagnostic purposes.

That's why 

  catch(std::exception& x) { std::cerr << x.what() <<std::endl; }

makes sense.

> I've never worked on a project of any size where this was even
> remotely plausible.

I think it's worth stretching your brain a little bit beyond your own
experience, especially when designing libraries.

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

It's not normal at all, IMO.  It's certainly a fine strategy, but many
people don't go to nearly those lengths.  Also, for example, boost
subsystems don't do any translation.

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

Excuse me, but the example was Bjarne's, and I don't think your
disdainful tone is warranted.

> 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 { ... }
> }

Then you really must grant that it could reasonably be appealing to
people who don't use your <disdainful term> MFC pattern of throwing
pointers to dynamically allocated objects, and can take advantage of
MI.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com