|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 09:08:03
Alan.Griffiths_at_[hidden] writes:
> I've recently been discussing the guideline recently added to the exceptions
> policy page with Dave Abrahams and he has asked me to post my views here.
>
> There is a seductive form of arguement that I've seen repeatedly lead
> projects into trouble which has made me very suspicious of the form:
> "provide X because someone might want to do Y". One common example is
> "provide public access to member data because someone might need to do
> something with the members that isn't supported directly". (I hope that
> this is a forum that would reject this argument.) Another arguement I've
> encountered recently is that "all classes should have a virtual destructor
> because someone may want to specialise them".
>
> The arguement is especially seductive when the cost of "providing X" is
> either small or hidden. But many a project has failed through creeping
> featuritis driven by such concerns. The cost of virtual inheritance from
> std::exception may well appear small - indeed, most of it is the
> intellectual cost of understanding the intent.
>
> Arguments of this form need to be challenged on the basis of whether "to do
> Y" is a reasonable expectation. If not, then the solution isn't "provide X"
> it is "discourage Y".
>
> Now, unlike the examples cited above, I've *never* encountered anyone
> arguing that exception hierarchies should be designed to support MI in a
> real design scenario. Nor, when challenged on this point, has Dave. The
> hypothetial example cited seems very implausible: when developing a
> subsystem to meet two interfaces I invariably develop a pair of adaption
> wrappers over the core functionality. (And, in general, repackaging of
> exceptions is a very small part of that wrapper.)
Alan, did you read
http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628
??
FWIW, the rest of the thread is
http://aspn.activestate.com/ASPN/Mail/Message/boost/1777712
> The obvious conclusion from the example cited is "don't multiply
> inherit from classes that are not designed to support it".
>
> I'm always willing to learn, but in the absence of a compelling
> example that MI is useful in exception heirarchies, I am unwilling
> to support the new guideline.
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.
-- 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