On Tue, 2003-09-02 at 18:06, [EMAIL PROTECTED] wrote: > > -----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.
An implementation of NFS. It would not know if the error was a network error or a file system error so it would throw netfile_err. OTOH an ftp client wouldn't need this as it could tell the difference. > > 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.) In certain places it may be the most natural design choice. Whether it is a good idea to pay for virtual inheritance in every exception derived from class exception is a separate issue. Exception handling incurs a significant cost once an exception is thrown. Adding to that cost could drive more users away from exception handling. Also, I'm not sure that this use case is sufficiently common to burden all exceptions with. /ikh _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
