TITLE: the utility of exception specifications

(Newsgroups: comp.lang.c++.moderated,comp.lang.c++,comp.std.c++, 9 Nov 97)


???:
	void f(int i) throw(A);    // function declaration


LEICHTER: Jerry Leichter

 > >> What the specification for f() above guarantees is that no caller for
 > >> f() will ever see an exception emerge from f() that is not (derived
 > >> from) A.  This is a *run-time* guarantee, and compilers are actually
 > >> required to accept code that, on its face, violates it:  The violation
 > >> can be eliminated at run time, and the programmer is allowed to try.
 > >> (Nevertheless, a good compiler should probably be able to emit a
 > >> warning, as designing your application around such fixups seems
 > >> dangerous.)


RILBE: Leif Rilbe <leif_rilbe@hotmail.com>

 > >Does anyone know anything about the rationale for not enforcing this
 > >guarantee at compile time? Seems to me that the lack of compile time
 > >check makes the mechanism far less usable than it would be otherwise.
 > >Especially a compile time check of the empty exception specification
 > >would be very useful for writing exception safe code. Are there any
 > >changes in the works in this regard?


CLAMAGE: Steve Clamage

 > A general principle in C++ (often violated) is that things that might
 > go wrong are not necessarily errors. For example, if you declare an
 > ambiguous set of overloaded functions, it is not an error unless you
 > actually make a call that is ambiguous.
 > 
 > Similarly, the potential for throwing an exception that violates the
 > exception specification is not an error. If we made the potential
 > undesired exception a compile-time error, we would then run into
 > problems like these:
 >         void foo(int*);
 >         void f1(int i) throw(int)
 >         {
 >                 foo(&i);
 >                 if( i < 3 )
 >                         throw "hello";
 >         }
 > Error? Not if foo exits by throwing an int exception, or if i>=3 after
 > the call to foo. The compiler in general cannot tell, and how much
 > global analysis should we require a compiler to do?
 > 
 > But there is also a stronger reason. If potentially disallowed
 > exceptions were errors, function f1 could not call function foo at all
 > without surrounding it with a try/catch clause, because foo might exit
 > via any exception. Worse, any time the exception specification of a
 > function changed, you would have to re-examine the code of every
 > function that called it, and the functions that called any of those
 > that changed, and so on. It seemed like that situation would make
 > exception specifications even less useful than they are under current
 > rules.


[ FYI this is precisely how Java works. -adc ]


HOPPS: kjhopps@mmm.com <Kevin J. Hopps>

By saying that you don't want the compiler to do this, you have not
saved me from this analysis.  Finding out about a bug triggered by a
violated exception specification is even more costly at run time.  I
agree that the compiler should not do this, but more relevant is that
this is a strong argument against using exception specifications at all
(except perhaps throw(), the "will not throw" specification).

Exception specifications are a guarantee, yes, but they also betray the
implementation somewhat.  At the very least, using an exception
specification on my function makes it very difficult for me to change
its implementation and still maintain my guarantee of what exceptions
can escape it.  This is especially true of template classes.  What
guarantees can you possibly make, having no idea of what "T" will be
used to instantiate the template?

I'm not sure if the benefit of exception specifications justifies the
cost of their use.