Boost logo

Boost :

From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2003-09-02 12:49:10

On Tue, 2003-09-02 at 18:06, Alan.Griffiths_at_[hidden] wrote:
> > -----Original Message-----
> > From: David Abrahams [mailto:dave_at_[hidden]]
> >
> > Alan, did you read
> >
> > ??
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at