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

From: Alan.Griffiths_at_[hidden]
Date: 2003-09-04 02:31:33

> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: 03 September 2003 19:54
>
> >> -----Original Message-----
> >> From: Bjarne Stroustrup [mailto:bs_at_[hidden]]
> >> Sent: 03 September 2003 16:57
> >>
> >> There wasn't much experience with exceptions at the time I 
> >> wrote that. I saw it 
> >> in a few examples and extrapolated. Note that the amount of 
> >> anti-MI hype tends 
> >> to eliminate even good examples from common use.

This confirms some of my doubts about the frequency of applicability of this
solution.

> >> I think that multiple inherited exception can be good design, 
> >> for all the usual reasons for MI. I don't think we 
> >> need to go to virtual bases.  That's a 
> >> complication that I don't see the need for. 

I agree that MI is often good design, but which of the "usual reasons" apply
to exception hierarchies?

> >> 
> >> The example quoted by Dave with the ambiguous what() should - 
> >> as ever - be resolved by overriding what() in the derived class.
> 
> I guess Bjarne misunderstood the example.  It had nothing to do with
> what() at all.

Agreed: I should have read more carefully before forwarding.  

> The problem is that if the exception has multiple std::exception base
> subobjects, a
> 
>   catch(std::exception const&)
> 
> clause will fail to catch the exception at all.  For people who are
> trying to avoid using catch(...) I consider this to be a terrible
> danger, since it happens only rarely, at runtime, and usually leads to
> termination.

It is over 20 years since I wrote an OS (and that was in assembler without
any exception handling) so I'm not familiar with that context.  But in the
business subsystems that I work with the design is such that this just
wouldn't happen (as exceptions get "translated"/"wrapped" at subsystem
boundaries to have a native meaning).

As already established, fundamentally the problem stems from broken
implementations - and any workaround will have issues.  We clearly give a
different importance to this gotcha.
-- 
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.
------------------------------------------------------------------------