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.