Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 12:45:38


Alan.Griffiths_at_[hidden] writes:

>> -----Original Message-----
>> From: David Abrahams [mailto:dave_at_[hidden]]
>>
>> 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.
         ^
       to be?

> 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.

It doesn't need to be. There's no denying that the error is both a
network and a file system error. In an OS design there's no reason
that the author of the FileSystem implementation can't have access to
exception classes from other parts of the OS.

> 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?

Dunno.

> It certainly isn't the only possible one. (Making all the code
> depend upon the definitions of both Network_err and File_system_err

Whoa, "all the code" means what, to you? AFAICT it means all the
code around the one function which throws the MI exception. Not much
if you really want to try hard to isolate dependencies.

> - 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. :)

Go for it ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk