X3J16/94-0084, WG21/N0471

1


Doc No:	X3J16/94-0084 WG21/N0471
Date:	27 May 94
Project:	Programming Language C++
Reply to:	Michael J. Vilot
ObjectCraft, Inc.
7 Colby Ct., suite #4P321
Bedford NH USA 03110P6427
mjv@objects.mv.com

Exception Specifications

This proposal is for another RfinalS decisions about the use of exception specifications in the Standard 
C++ library.

This proposal revisits an issue that was decided by the Library WG in March, 1990 (see: X3J16/90P
0052, X3J16/90P0062), again in November, 1991 (91P0134/N0067), and again in November, 1992 (92P
0129/N0206, 92P0132/N0208).

2.	Proposal

There are two alternatives to consider.  Only one should be adopted.

Alternative 1:

All exception-specifications should be removed from the Standard C++ library.  The feature should 
also be removed from the language.

[Editorial note:  remove subclause $15.5, Exception specifications (_except.spec_).  Remove &3 in 
$8.1, Type names (_dcl.name_).]

Alternative 2:

Exception-specifications should be used throughout the Standard C++ library, as appropriate.

[Editorial note:  restore the exception-specifications  used in proposals X3J16/92-0084/N01061 as 
voted on and approved in November, 1992; 93P0013R1/N0221R1 as voted on and approved in 
March, 1993; 93P0012R1/N0220R1 as voted on and approved in March, 1993; 93P0045/N0252 
as voted on and approved in March,1993; 93P0060/N0267 as voted on and approved in July, 
1993; 93P0064/N0271 as voted on and approved in July, 1993]

3.	Discussion

The use of exception-specifications  seems to have been quietly dropped in the San Diego rewrite of 
Clause 17.  Critics of the feature declare exception-specifications  are useless, and should be removed.  If 
so, this should be done as an explicit decision by X3J16/WG21, not as a quiet editorial change.

On the other hand, they may be a useful feature.  During the discussion of the above-cited proposals, 
there were no technical difficulties encountered with using exception-specifications  as part of the 
specification of Standard C++ library components.

The most significant objection was the need to introduce exception-specifications  for the xalloc 
exception to just about every function signature.  This was an attempt to avoid over-specification Q any 
implementation might choose to use dynamic storage to manage the internal state of any Standard 
library component.  Since any of these operations might provoke an xalloc exception, it seemed 
unavoidable that such exceptions would have to be propagated to the program instead of calling 
unexpected.  Hence the need for xallocs in exception-specifications  throughout the library.

Documenting this possibility in exception-specifications  was replaced in the San Diego rewrite with the 
single sentence in $17.1.5.2, Restrictions on exception handling (_lib.res.on.exception.handling_):

RAny of the functions defined in the Standard C++ library can report a failure to allocate storage 
by calling ex.raise() for an object ex of type xalloc.S

The issue boils down to deciding whether to document the interface with a language feature, or a 
comment.