R
raj s
What is the advantage and disadvantage of using function declaration
with exceptions specified.
like foo()throws(char&)
with exceptions specified.
like foo()throws(char&)
E
Erik Wikström
If you have a function with an exception specification you can work
under the assumption that the function only throws exceptions of the
specified kind. In other words you do not have to check for other kinds
of exceptions in your handlers.
The drawback is that if an exception not listed in the specification is
thrown in the function (or by a function called by the function) which
is not also caught in the function, your program will call unexpected()
which will usually terminate your application.
S
Salt_Peter
Exceptions are always specified.
If foo() did not have an explicit exception specification then it
could throw any kind of exception.
void foo() { } // throws(anything)
however,
foo() throws() { }
then the contract says foo shall throw no exception.
If the program breaks the contract C++ calls terminate().
In your example, if foo threw anything else but a char, terminate()
gets called.
R
red floyd
And a minor nitpick it's void foo() throw(char&), not *throws*.
And I could have sworn it's in the FAQ, but I can't find it; in
general use of exception specifications with the exception of nothrow
[void foo() throw() { }] is discouraged because it doesn't enforce at
compile time (cf. Java).
E
Erik Wikström
Actually, unexpected() is called and it can throw an exception in the
specification (or call terminate()) which will then be thrown by the
function instead of the original exception.
J
James Kanze
It specifies a contract, enforced by the compiler. The contract
is a negative one, however: the exception specification
guarantees that you will not get any exceptions of the given
type from the function, not that the function will actually
throw any of the listed exceptions when appropriate. As such,
it's almost always only useful when the guarantee is that the
function won't throw anything. (I'm willing to admit that there
may be exceptions to this, when the guarantee that the function
won't throw anything but one particular type of exception might
be useful. But I've never encountered it.)
J
James Kanze
How is that a drawback? It's more or less the same behavior as
an assertion failure.
R
red floyd
Uh, James, I think you got that backward. I believe that 15.4/7 says
that the function is allowed to throw the listed exceptions, anything
else gets routed to unexpected(), per 15.4/8.
J
James Kanze
Yes. Somehow, the word "except" didn't get typed in; it should
have been "[...]the exception specification guarantees that you
will not get any exceptions except of the given type from the
function".
The point remains that the "contract" which will be enforced is
a negative one. It's not "you will get[...]", but "you will not
get[...]".
In practice, there are two guarantees which are useful:
-- The guarantee absolute that the function won't throw. This
makes a rigorous analysis of the calling code much easier
(because it eliminates the additional flow control paths
introduced by exceptions), and is in fact necessary for a
few operations at the lowest level. (The swap idiom for
assignment, for example, is only valid if the swap functions
used are guaranteed not to throw.)
-- The guarantee that certain error conditions will be
correctly reported by means of the specified exception.
An empty exception specification in C++ can be used to ensure
the first. I don't think there is any possible language
mechanism which could be used to ensure the second, since it
depends on concrete semantics.
Note too that despite syntactic similarities, the Java exception
specification plays an entirely different role: the significant
contract it imposes is on the client code, not on the function
itself: it requires the client code to explicitly handle the
error immediately. In most cases, a return code would be more
appropriate, and the corresponding idiom in C++ is to use a
return code with a type which aborts (assertion failure) if the
destructor is called without the return code having been read.
A
Andrey Tarasevich
raj said:
After all that was said, one question that still remains is, of course,
why on Earth would anyone choose to specify a _reference_ type in the
exception specification.
E
Erik Wikström
It is a drawback because the exception specifications are not checked at
compile-time. So when you a year later makes a change in one part of the
code and miss the fact that one of the functions have a specification
you run the risk of getting some unpleasant surprises.
Don't get me wrong, I like the idea that you can limit which exceptions
can be thrown but with the current implementation its usefulness is
limited to basic functions and very hard to apply to more general functions.
M
Marcus Kwok
Here is a good article on why exception specifications aren't really
very useful:
http://www.gotw.ca/gotw/082.htm
J
James Kanze
Nor is overflow during an addition
.Seriously, the more static checking the better. But in this
case, static checking would probably require inter-module flow
analysis to be done correctly. If only for historical reasons:
there are an awful lot of functions out there without exception
specifications (and thus, which can, formally, throw anything)
which in fact never throw.
If you change an interface, you can expect unchanged code which
uses that interface to stop working. Regardless of which part
of the contract you change. The only particular problem here is
that a lot of functions don't correctly document this part of
the interface, so some guessing is involved. And when you guess
wrong, bad things happen.
I don't find this to be the case. In most cases, except at the
lowest levels, you don't want to contractually guarantee that
your function won't throw---if you're not a leaf function,
you're dependent on the functions you call, and unless they're
doing something very primitive, you do't want to restrict their
possibilities.