JTC1/SC22/WG21
N0741
Doc No : X3J16/95-0141 WG21/N0741
Date : 1995-07-11
Project : Programming Language C++
Reply to : Mats Henricson
mats.henricson@eua.ericsson.se
Exceptions specifications in the Standard Library
-------------------------------------------------
The public comment from Marc Shepherd is:
The use of exception specifications in the Library clauses is
incomplete and inconsistent. It is too soon to tell how extensively
C++ exceptions will be used, but I believe a user would want an
iron-clad promise about what exceptions a library function might
throw. Therefore, unless there is a good reason to the contrary,
every Library function (except those inherited from C) should have
an exception specification.
First, some functions in the C++ Library today have explicit exception-
specifications. All of them have been put there after lots of pain and
tough debates. We intend to keep them in the library, so what remains
to talk about are the functions that today have no exception
specifications at all.
There are three possibilities for how to handle this:
1. Have explicit exception-specifications for all functions in the
library, listing exactly all possible exceptions, i.e.:
void foo() throw(X,Y)
This overconstrains the implementation of libraries.
2. Have an explicit exception-specification that says all functions in
the library throws exceptions derived from exception, i.e.:
void foo() throw(exception);
The problem with this approach is that it gives no real help to the
user of foo(). It is possible to catch an exception, but nothing
can be done with it, unless you downcast it, which is not an idiom
we are supporting. It may also encourage pollution of the standard
library exception hierarchy.
3. Have an implicit exception-specification that says that functions
may throw anything, i.e.:
void foo();
The problem with this approach is that gives the user no "promise
about what exceptions a library function might throw". The way out
would be to allow implementors to strengthen this "may throw
anything" specification by explicitly listing what their
implementation may throw.
We have chosen to do it the last way.
======================================================================
Kind of a summary, and further explanation:
1. Lets get rid of the simple things first; the C library. Since the C
library shall be possible to implement in C, we must say that it
does not throw exceptions. There are however a few C functions that
might call user-defined C++ functions that can throw exceptions.
qsort() is an example. Therefore I suggest adding to 17.3.4.8
(Restrictions on exception handling):
None of the functions from the Standard C library shall report an
error by throwing an exception, unless it calls a user-defined
function that throws an exception. [footnote1] [footnote2]
[footnote1] That is, the C library functions are all specified as
if they have a throw() exception-specification.
[footnote2] qsort() is such an example.
2. Wherever there is an explicit exception specification for a function,
say:
void foo() throw(X,Y);
it can only throw such exceptions. An implementation of the standard
library may strengthen this specification by removing one or many or
all of the exceptions listed in the exception specification.
void foo() throw(X); // OK
void foo() throw(Y) // OK
void foo() throw(); // OK
void foo() throw(X,Y,Z); // Not OK
3. Functions which have no explicit exceptions specifications can throw
any exception. An implementation may strengthen this specification by
explicitly stating what exceptions that can be thrown from their
specific implementation. An explicit exception specification is always
a strengthening if none are specified by the standard.
======================================================================
This all means that I would like to rewrite 17.3.4.8 to be:
17.3.4.8 Restrictions on [lib.res.on.exception.handling]
exception handling
1 None of the functions from the Standard C library shall report an
error by throwing an exception, unless it calls a user-defined
function that throws an exception. [footnote1] [footnote2]
2 Any of the functions defined in the C++ Standard library can report a
failure by throwing an exception of the type(s) described in their
Throws: paragraph and/or their exception-specification. An
implementation may strengthen the exception-specification for a
function by removing listed exceptions.
3 Any of the functions defined in the C++ Standard library that do not
have an exception-specification may throw any exception. An
implementation may strengthen this implicit exception-specification by
adding an explicit exception-specification.
-----
[footnote1] That is, the C library functions are all specified as
if they have a throw() exception-specification.
[footnote2] qsort() is such an example.