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

From: Alan.Griffiths_at_[hidden]
Date: 2003-09-02 12:06:44

> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> 
> Alan, did you read
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628
> ??

I have, but (leaving aside the argument from authority) the example is too
sketchy convincing.

I don't see how any individual error will be thrown from a point that is
part of both the "Network" API and the "File_system" API.  I can see how a
function that throws may be be called indirectly in the implementation of
either API - and that the MI solution avoids catching and "translating" the
exception.

But is this a good design?  It certainly isn't the only possible one.
(Making all the code depend upon the definitions of both Network_err and
File_system_err - which no doubt drags other stuff into the translation unit
- isn't a design choice I'd make lightly.)

> I'm feeling ambivalent about it now, but I do think Bjarne's example
> is a pretty good one, and I wouldn't guess he'd claim it happens
> "often" without some evidence.

Two points:

/1/ I've seen specialisation of classes not designed for inheritance more
often than I've see this.  (And I suspect you have too.)

/2/ Instead of guessing we can ask him.  He is amazingly tolerant of idiot
questions.  :)

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

------------------------------------------------------------------------