TITLE: the cost of a throw() clause

(Newsgroups: comp.std.c++, 1 Apr 98)


SMITH: Ross Smith <ross.smith@nz.eds.com>

>It's common (at least the way I code) for code to check
>or transform its arguments and proceed only when it's in a consistent
>state, so that subsequent function calls are known not to throw.


BELL: abell8920@mindspring.com (Andrew Bell)

I'd hope that any compiler that implemented such a warning to be able
to disable it with a pragma.


SMITH:

>    double pythagoras(double x, double y) throw () {
>      return square_root(x * x + y * y);
>    } // ... Bzzt! false warning


BELL:

The problem is, unless the compiler has access to the definition of
square_root and is very smart, it will have to implement pythagoras as
if it were:

double pythagoras(double x, double y) throw () {
	try {
	      return square_root(x * x + y * y);
	}
	catch (domain_error) {
		while (1) {
			try {
				unexpected();
			}
			catch (domain_error) {
			}
		}
	}
}

You won't see this as a programmer, but object-code-wise it will be
there.  That's a lot of extra object code just for adding a throw
specifier, and could discourage people from using throw() specifiers
to begin with.

If the compiler has the smarts to figure out that square_root won't
throw and thus not add the extra code, it's smart enough to not give
the "violated throw specifier" warning Marc Sherman and I would like
anyway.

Ideally, we'd have some sort of preconditions stated in the interface,
and a smart compiler.  In that case, the > 0 test in square_root would
be a precondition, and thus known to the compiler as it compiles
pythagoras().  If the compiler is smart enough to realize that x * x
is > 0 for all x (at least for doubles -- note that for integer types
overflow is a possibility), and the sum of positive doubles is > 0,
the precondition will always be satisfied.