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

From: Alan.Griffiths_at_[hidden]
Date: 2003-09-08 10:12:30

> -----Original Message-----
> From: Daron Anderson [mailto:dnanderson_at_[hidden]]
> 
> 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.  

Thanks Daron for confirming that this practice isn't soley an abberation of
mine.  And confirming the view that "no MI" is a viable design guideline for
exception hierarchies.  Client code written to these rules would not benefit
from the proposed guideline.

But, regardless of what you or I do, users of boost can multiply inherit
from the boost exceptions and from another hierarchy that also inherits from
std::exception.  If they also try to catch the resulting exceptions as a
reference to the std::exception base class then they may be surprised at the
result if they don't realise that it is ambiguous.

This is a typical issue with MI: classes (exceptions or otherwise) that are
not designed for it should be extended in this way with extreme caution
because "fixes" in the derived class are problematic.
-- 
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.
------------------------------------------------------------------------