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

From: Daron Anderson (dnanderson_at_[hidden])
Date: 2003-09-05 23:19:23

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

I have had much success using this 'wrapping' approach.  On one of the
projects I am working on, I have required that all team members catch all
exceptions not derived from std::exception at the subsystem/package level
and only rethrow specialisations of std::exception.  I have also required
that no MI be used in exception hierarchies.  The result is that it can be
guaranteed that "catch( std::exception& ex )" will catch all exceptions
emitted from the code that we are developing.  I also have several members
on my team that have little or no experience with exception handling.  This
guarantee has eased their transition from error return codes to exception
handling, since they only have to deal with an single exception hierarchy
that is a tree (and it has made it much easier to deal with exceptions
generated from the code they write).

The final benefit of this approach is that there is absolutely no
"catch(...)" blocks in this project.  This implies that no matter what
exception is caught, you always have at least a what() string to get
information about the error that occured.  I have found that to be immensely
benificial during debugging sessions, especially in a project that is
rapidly approaching 300,000 lines of code.  Previous experiences with
"catch(...)" have left me guessing about what errors occurred and I lost
many hours trying to resolve the issues.  I, like so many other programmers,
don't have the time to spend tracking down these kinds of exceptions, so we
just 'designed' them away.  I admit that, at times, this requires some extra
work to implement, but the time saved during testing/debugging seems to far
outweigh the initial investment.

Just my two cents, based on my personal experience.