> > There are also technical reasons speaking against exception
> > specifications. An ISO C++ conformant compiler checks exceptions
> > thrown by the implementation against the exception specification if
> > present. This results in the unexpected_handler/abort being called if
> > the implementation throws an exception it isn't declared in the IDL to
> > throw.
> If implementation throws unspecified exception then it violates the
> contract and calling abort is not necessarily the worse thing to do.
We removed exception specifications mainly because they are are a real
1) An exception specification does not help the implementer of a
I can write all the exception specifications I like and still call
anything that might throw anything inside the body of a member
function. Exception specifications are not statically checked, so if
my function promises to throw no exceptions at all and I call
something in the function that might throw, the compiler will not
pull me up.
2) An exception specification does not help the caller of a member
When I see a member function definition with an exception
specification, I am *not* promised that the function will throw only
the exceptions listed in the exception specification. Instead, what
I'm promised is that the function will not throw, will throw one of the
listed exceptions, or will call unexpected(). In turn, that is no guarantee
either, because even unexpected() may do unexpected things, such as
*not* calling abort(), namely, if it has been replaced. (I guess this
means that unexpected() has been named most aptly... ;-)
3) I cannot prevent the call to unexpected().
If a function with an exception specification throws an illegal
exception, I have no way to prevent the call to unexpected(). (Yes, I
can replace unexpected(), but only once, at global scope, which is
frowned upon, just as is replacing global operator new.) So, there is
no way to take corrective action in this case (as would be needed in
order to correctly throw UNKNOWN for CORBA).
4) Exception specifications subvert the type system in subtle ways.
Have a look through the last year's issues of CUJ. Herb Sutter wrote
an interesting example that shows subtle changes in the semantics of
overload resolution (from memory) that were caused by exception
specifications. (Sorry, I don't have the issues handy, so I can't
give a more precise reference.) From memory, Scott Meyers also has a
few non-complimentary things to say about exception specifications
(see "More Effective C++").
So, exception specifications are one of the very few true mis-features
in C++ and we decided that we were better off without them.
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc. http://www.zeroc.com