Re: Exception specification checked at *runtime*?
On Nov 1, 11:06 pm, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
On 2007-11-01 20:38, Paul Brettschneider wrote:
I wanted to start adding exception specifications (via
throw(...)) to a project of mine, since it looked like a
good idea for the sake of documentation, giving
optimisation-hints to the compiler and getting better
compiler warnings.
It is my understanding that the use of exception
specifications is generally discouraged for a number of
reasons, one of them being that it does not give you any
performance boost, on the contrary it can slow your code down.
In the words of Herb Sutter:
<quote>
In brief, don't bother. Even experts don't bother.
Slightly less briefly, the major issues are:
Exception specifications can cause surprising performance
hits, for example if the compiler turns off inlining for
functions with exception specifications.
Bad compiler. Don't use it:-).
A runtime unexpected() error is not always what you want to
have happen for the kinds of mistakes that exception
specifications are meant to catch.
The question is: what kinds of mistakes are exception
specifications meant to catch?
You generally can't write useful exception specifications for
function templates anyway because you generally can't tell
what the types they operate on might throw.
Again, the question is: what is a useful exception
specifications.
</quote>
You can also read the Boost exception specification rationale
on their
site:http://www.boost.org/more/lib_guide.htm#Exception-specification
I think the one exception to the rule is to use the empty
exception specification to indicate that no exceptions will
ever be thrown.
For documentation a comment with the function will work just
as well.
It depends.
The general problem is that exception specifications (generally)
don't tell you enough to be useful. It's not enough to know
that a function might throw std::runtime_error; if you're
counting on it for error reporting, you need to know the
conditions under which it will throw it, and you need a
guarantee that it will actually throw it when those conditions
occur. Exception specifications don't help here; they don't
provide enough information.
The other thing you sometimes have to know is that certain
exceptions can't occur. Typically (and I've yet to find an
atypical case), this is only relevant if the set of exceptions
is all of them: in order to write correct exception safe code,
you need some operations which are guaranteed not to throw,
period, as part of their contract. An empty throw() documents
this very well, *and* enforces it. As such, it's quite
compatible with programming by contract, in which violations of
the contract result in an assertion failure. The important
thing is that when you see a throw() on a function, you know,
absolutely, that no exception will escape from that function; if
the author of the function makes an error, and does try to
propagate one, you get an abort(), exactly like you would if an
invariant check failed, or whatever.
This has nothing to do with performance. The question is
really: what are you using exceptions for? If the exception is
designed to propagate up through many layers of function calls,
then exception specifications are counter-productive: the whole
point of using exceptions is that the intermediate layers don't
need to know about the error conditions in the lower layers. If
the exception is designed to be processed immediately, by the
calling function, then return values are more appropriate---you
shouldn't be using exceptions anyway.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34