This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110c. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2023-02-07


475. When is std::uncaught_exception() true? (take 2)

Section: 14.6.3  [except.uncaught]     Status: C++11     Submitter: Martin Sebor     Date: 27 Sep 2004

[Voted into WP at August, 2010 meeting.]

See also issue 37.

Given this piece of code and S having a user-defined ctor, at precisely which point must std::uncaught_exception() return true and where false?

    try { S s0; throw s0; } catch (S s2) { }

My understanding of the semantics of the code is as follows:

  1. The throw expression creates a temporary for a copy of s0, say s1, using the copy ctor of S. In this invocation of the copy ctor uncaught_exception() must return true.
  2. s0 is destroyed during stack unwinding. In the invocation of S dtor uncaught_exception() must still return true.
  3. The variable s2 is initialized from s1 by invoking the copy ctor of S. In this invocation uncaught_exception() must also return true.
  4. s2 and s1 are destroyed. In the invocations of S dtor uncaught_exception() must return false.

Is my understanding correct?

14.2 [except.throw] paragraph 3 talks about “the exception object” when describing the semantics of the throw-expression:

a throw-expression initializes a temporary object, called the exception object...

However, 14.6.2 [except.terminate] paragraph 1 talks about “the expression to be thrown” when enumerating the conditions under which terminate() is called:

when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (14.2 [except.throw]), calls a user function that exits via an uncaught exception...

And, 14.6.3 [except.uncaught] paragraph 1 refers to “the object to be thrown” in the description of uncaught_exception():

The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown...

Are all these objects one and the same? I believe the answer is important in case the construction of the temporary exception object throws another exception.

Suppose they are the same. Then uncaught_exception() invoked from the copy ctor for s1 (from the example [above]) must return false and a new exception (e.g., bad_alloc) may be thrown and caught by a matching handler (i.e., without calling terminate()).

But if they are not the same, then uncaught_exception() invoked from the copy ctor for s1 must return true and throwing another exception would end up calling terminate(). This would, IMO, have pretty severe consequences on writing exception safe exception classes.

As in the first case, different compilers behave differently, with most compilers not calling terminate() when the ctor for the temporary exception object throws. Unfortunately, the two compilers that I trust the most do call terminate().

FWIW, my feeling is that it should be possible for the copy ctor invoked to initialize the temporary exception object to safely exit by throwing another exception, and that the new exception should be allowed to be caught without calling terminate.

Mike Miller: The way I see this, a throw-expression has an assignment-expression as an operand. This expression is “the expression to be thrown.” Evaluation of this expression yields an object; this object is “the object to be thrown.” This object is then copied to the exception object.

Martin Sebor: Here's a survey of the return value from uncaught_exception() in the various stages of exception handling, implemented by current compilers:

expr temp unwind handlr 2nd ex
HP aCC 6 0 0 1 0 OK
Compaq C++ 6.5 0 0 1 1 ABRT
EDG eccp 3.4 0 1 1 1 ABRT
g++ 3.4.2 0 0 1 0 OK
Intel C++ 7.0 0 0 1 0 OK
MIPSpro 7.4.1 0 0 1 1 ABRT
MSVC 7.0 0 0 1 0 OK
SunPro 5.5 1 1 1 0 OK
VisualAge 6.0 0 1 1 1 OK

In the table above:

Proposed resolution (October, 2004):

  1. Change 14.2 [except.throw] paragraph 3 as follows:

    A throw-expression initializes a temporary object, called the exception object, the by copying the thrown object (i.e., the result of evaluating its assignment-expression operand) to it. The type of which the exception object 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. [Note: the temporary object created for by a throw-expression that whose operand is a string literal is never of type char* or wchar_t*; that is, the special conversions for string literals from the types “array of const char” and “array of const wchar_t” to the types “pointer to char” and “pointer to wchar_t,” respectively (7.3.3 [conv.array]), are never applied to the operand of a throw-expression. —end note] The temporary is an lvalue and is used to initialize the variable named in the matching handler (14.4 [except.handle]). The type of the operand of a throw-expression shall not be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void. [...]
  2. Change the note in 14.4 [except.handle] paragraph 3 as follows:

    [Note: a throw-expression operand that which is an integral constant expression of integer type that evaluates to zero does not match a handler of pointer type; that is, the null pointer constant conversions (7.3.12 [conv.ptr], 7.3.13 [conv.mem]) do not apply. —end note]
  3. Change 14.6.2 [except.terminate] bullet 1.1 as follows:

    when the exception handling mechanism, after completing evaluation of the expression to be thrown operand of throw but before the exception is caught (14.2 [except.throw]), calls a user function that exits via an uncaught exception,
  4. Change 14.6.3 [except.uncaught] paragraph 1 as follows:

    The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown operand of throw until completing the initialization of the exception-declaration in the matching handler (_N4140_.18.8.4 [uncaught]).
  5. Change _N4140_.18.8.4 [uncaught] paragraph 1 by adding the indicated words:

    Returns: true after completing evaluation of the operand of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate(). [Note: This includes stack unwinding (14.3 [except.ctor]). —end note]

Notes from the April, 2005 meeting:

The CWG discussed this resolution both within the group and with other interested parties. Among the points that were made:

The CWG felt that more input from a wider audience was necessary before a decision could be made on the appropriate resolution.

Notes from the April, 2006 meeting:

The CWG agreed with the position that std::uncaught_exception() should return false during the copy to the exception object and that std::terminate() should not be called if that constructor exits with an exception. The issue was returned to “drafting” status for rewording to reflect this position.

Additional notes (September, 2007):

Although this issue deals primarily with when std::uncaught_exception() begins to return true, the specification of when it begins to return false is also problematic. There are two parallel sections that define the meaning of std::uncaught_exception() and each has a different problem. 14.6.3 [except.uncaught] reads,

The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown until completing the initialization of the exception-declaration in the matching handler (_N4140_.18.8.4 [uncaught]).

The problem here is that whether an exception is considered caught (the underlying condition tested by the function) is here presented in terms of having initialized the exception-declaration, while in other places it is specified by having an active handler for the exception, e.g., 14.2 [except.throw] paragraph 6:

An exception is considered caught when a handler for that exception becomes active (14.4 [except.handle]).

This distinction is important because of 14.4 [except.handle] paragraph 3:

A handler is considered active when initialization is complete for the formal parameter (if any) of the catch clause. [Note: the stack will have been unwound at that point. —end note] Also, an implicit handler is considered active when std::terminate() or std::unexpected() is entered due to a throw.

Note that there is no exception-declaration to be initialized for the std::terminate() and std::unexpected() cases; nevertheless, according to _N4140_.18.8.4 [uncaught], std::uncaught_exception() is supposed to return false when one of those two functions is entered.

The specification in _N4140_.18.8.4 [uncaught] is not well phrased, however, and is open to misinterpretation. It reads,

Returns: true after completing evaluation of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate().

The problem here is lack of parallelism: does “after entering terminate” refer to the condition for returning true or false? This would be better phrased along the lines of

Returns: true after completing evaluation of a throw-expression until a handler for the exception becomes active (14.4 [except.handle]).

Proposed resolution (March, 2010):

  1. Change 14.6.2 [except.terminate] bullet 1.1 as follows:

  2. In the following situations exception handling must be abandoned for less subtle error handling techniques:

  3. Change 14.6.3 [except.uncaught] paragraph 1 as follows:

  4. The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown the initialization of the exception object (14.2 [except.throw]) until completing the initialization of the exception-declaration in the matching handler activation of a handler for the exception (14.4 [except.handle], _N4140_.18.8.4 [uncaught])...
  5. Change _N4140_.18.8.4 [uncaught] paragraph 1 as follows:

  6. Returns: true after completing evaluation of a throw-expression initializing an exception object 14.2 [except.throw] until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate() a handler for the exception (including unexpected() or terminate()) is activated (14.4 [except.handle]). [Note: This includes stack unwinding (14.3 [except.ctor]). —end note]