Re: Exception specifications unfortunate, and what about their future?
on Fri Dec 12 2008, Eugene Gershnik <gershnik-AT-gmail.com> wrote:
On Dec 10, 7:39 am, David Abrahams <d...@boostpro.com> wrote:
Some things just don't need to be checked at compile-time. Can you
imagine having to declare every derived class that can come out of a
factory function?
struct Base { virtual ~Base(); };
std::auto_ptr<Base> factory() emits(Derived1, Derived2, ...
DerivedN);
It amounts to the same thing for correctness, maintainability,
coupling,
etc.: a nightmare.
This is a false analogy.
Disagreed.
When you use interfaces and factories the clients generally are
expected to use the interface and never care about the derived type.
Exactly.
In case of exceptions such useful base interface does not exist in any
language[1]. An no std::exception is not it. Its "interface" is
somewhat equivalent to uber-objects of OO languages. That is it is
mostly useless.
In the case of exceptions, the vast majority of clients are expected to
use the (empty) interface.
(As an aside, you cannot even clone it
That's fixed in C++0x, for all exceptions.
or get a decent user-level error message out of it.
For decent user-level error messages, you'd better not try to build
formatting into the exception object anyhow.
And, unfortunately, exceptions don't even have to derive from it.
Why should they have to? The common interface is empty.
In any event, speaking of correctness, maintainability and coupling,
*every* decent library out there (in every language) already supplies
"exception specifications" for all externally visible functions in its
documentation. Actually not having this information is a sure sign of
a bad library. Of course, these ES don't do what people naively expect
them to do, for example list *all* possible exceptions/errors (usually
they list only the 'significant' ones). Still, apparently this
information is necessary and somebody has to work on compiling and
maintaining this documentation anyway. When he gets it wrong people
fill the internet with question like 'Why FooBar API doesn't return
E_PROBLEM when documentation says it should?'.
Interesting. I've never, ever seen such a question asked about a C++
interface that uses exceptions.
So why would it be wrong to have the compiler help this poor guy? ;-)
Because the cost of taking advantage of that help outweighs any
correctness advantages it might offer, which incidentally are very few.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]