[EMAIL PROTECTED] writes: >> -----Original Message----- >> From: David Abrahams [mailto:[EMAIL PROTECTED] >> Sent: 02 September 2003 18:46 >> > >> > /2/ Instead of guessing we can ask him. He is amazingly >> tolerant of idiot >> > questions. :) >> >> Go for it ;-) > > Done: here is what he has to say (with my summary of the discussion elided > for brevity)... > >> -----Original Message----- >> From: Bjarne Stroustrup [mailto:[EMAIL PROTECTED] >> 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. >> >> >Are you still of the opinion that this design is both common and good >> >practice? And have you time to explain why? >> >> 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. >> >> 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. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
