> -----Original Message----- > From: David Abrahams [mailto:[EMAIL PROTECTED] > > 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. ------------------------------------------------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
