Re: function with exception's declared
On Sep 16, 7:22 pm, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
On 2008-09-15 23:18, James Kanze wrote:
On Sep 15, 6:13 pm, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
On 2008-09-15 11:54, raj s wrote:
What is the advantage and disadvantage of using function declaration
with exceptions specified.
like foo()throws(char&)
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 kind=
s
of exceptions in your handlers.
The drawback is that if an exception not listed in the specification i=
s
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.
How is that a drawback? It's more or less the same behavior
as an assertion failure.
It is a drawback because the exception specifications are not
checked at compile-time.
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.
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.
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.
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.
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.
--
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