This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Moved to DR at the October, 2012 meeting.]
There are a number of places in the Standard that appear to assume that exceptions are only thrown by throw-expressions. Various other constructs, such as dynamic_casts, typeid, new-expressions, etc., can also throw exceptions, so a more general term should be coined and applied in place of throw-expression wherever necessary.
Proposed resolution (February, 2012):
Change 22.214.171.124.2 [basic.stc.dynamic.allocation] paragraph 3 as follows:
...Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception of a type that would match a handler (14.4 [except.handle]) of type std::bad_alloc (126.96.36.199 [bad.alloc]).
Change 188.8.131.52.2 [basic.stc.dynamic.allocation] paragraph 4 as follows:
...[Note: In particular, a global allocation function is not called to allocate storage for objects with static storage duration (184.108.40.206 [basic.stc.static]), for objects or references with thread storage duration (220.127.116.11 [basic.stc.thread]), for objects of type std::type_info (18.104.22.168 [expr.typeid]), or for
the copy of an object thrown by a throw expression(14.2 [except.throw]). —end note]
Change 22.214.171.124 [expr.dynamic.cast] paragraph 9 as follows:
The value of a failed cast to pointer type is the null pointer value of the required result type. A failed cast to reference type throws std::bad_cast (17.7.4 [bad.cast]).
Change 126.96.36.199 [expr.typeid] paragraph 2 as follows:
...If the glvalue expression is obtained by applying the unary * operator to a pointer68 and the pointer is a null pointer value (7.3.12 [conv.ptr]), the typeid expression throws
thestd::bad_typeid exception (17.7.5 [bad.typeid]).
Change 188.8.131.52 [expr.new] paragraph 7 as follows:
When the value of the expression in a noptr-new-declarator is zero, the allocation function is called to allocate an array with no elements. If the value of that expression is less than zero or such that the size of the allocated object would exceed the implementation-defined limit, or if the new-initializer is a braced-init-list for which the number of initializer-clauses exceeds the number of elements to initialize, no storage is obtained and the new-expression
terminates by throwingan exception of a type that would match a handler (14.4 [except.handle]) of type std::bad_array_new_length (184.108.40.206 [new.badlength]).
Change Clause 14 [except] paragraph 1 as follows:
...A handler will be invoked only by
a throw-expression invokedin code executed in the handler's try block or in functions called from the handler's try block ...
Change Clause 14 [except] paragraph 2 as follows:
A try-block is a statement (Clause 8 [stmt.stmt]). A throw-expression is of type void.
Code that executes a throw-expression is said to “throw an exception;” code that subsequently gets control is called a “handler.”[Note:...
Change 14.2 [except.throw] paragraph 1 as follows:
Throwing an exception transfers control to a handler. An object is passed and the type of that object determines which handlers can catch it. [Example:...
Change 14.2 [except.throw] paragraph 3 as follows:
A throw-expressioncopy-initializes (9.4 [dcl.init]) a temporary object, called the exception object , the type of which is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T”, respectively. The temporary is an lvalue and is used to initialize the variable named in the matching handler (14.4 [except.handle]). If the type of the exception object would be an incomplete type or a pointer to an incomplete type other than (possibly cv-qualified) void the program is ill-formed. Except for these restrictions and the restrictions on type matching mentioned in 14.4 [except.handle], the operand of throw is treated exactly as a function argument in a call (220.127.116.11 [expr.call]) or the operand of a return statement.
Change 14.2 [except.throw] paragraph 4 as follows:
anexception thrown by a throw-expressiondoes not propagate to other threads unless caught, stored, and rethrown using appropriate library functions; see 17.9.7 [propagation] and 33.10 [futures]. —end note]
Change 14.2 [except.throw] paragraph 8 as follows:
A throw-expression with no operand rethrows the currently handled exception (14.4 [except.handle]). The exception is reactivated with the existing
temporary; no new temporaryexception object is created. The exception is no longer considered to be caught; therefore, the value of std::uncaught_exception() will again be true. [Example:...
Change 14.3 [except.ctor] paragraph 1 as follows:
As control passes from
a throw-expressionto a handler, destructors are invoked for all automatic objects constructed since the try block was entered...
Change 14.3 [except.ctor] paragraph 3 as follows:
The process of calling destructors for automatic objects constructed on the path from a try block to
a throw-expressionis called “stack unwinding.” If a destructor...
Change 14.4 [except.handle] paragraph 17 as follows:
When the handler declares
a non-constantobject, any changes to that object will not affect the temporary object that was initialized by execution of the throw-expression. When the handler declares a reference to a non-constantobject, any changes to the referenced object are changes to the temporary object initialized when the throw-expression was executedand will have effect should that object be rethrown.
Change 18.104.22.168 [terminate] paragraph 1 as follows:
Remarks: Called by the implementation when exception handling must be abandoned for any of several reasons (14.6.2 [except.terminate]), in effect immediately after
evaluating the throw-expression (22.214.171.124 [terminate.handler]). May also be called directly by the program.