This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

1369. rethrow_exception may introduce data races

Section: 17.9.7 [propagation] Status: NAD Submitter: BSI Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [propagation].

View all issues with NAD status.

Discussion:

Addresses GB-74

One idea for the exception_ptr type was that a reference-counted implementation could simply 'reactivate' the same exception object in the context of a call to rethrow_exception. Such an implementation would allow the same exception object to be active in multiple threads (such as when multiple threads join on a shared_future) and introduce potential data races in any exception handler that catches exceptions by reference - notably existing library code written before this capability was added. rethrow_exception should always make a copy of the target exception object.

[Resolution suggested by NB comment]

Add the following to 18.8.5, [propogation]

Throws: a copy of the exception object to which p refers.

[2011-03-15: Anthony drafts wording]

[2011-03-23 Madrid meeting]

No consensus for a change

Rationale:

It would break too many existing implementations

Proposed resolution:

  1. Alter 14.2 [except.throw] p. 5 as follows:

    5 When the thrown object is a class object, the copy/move constructor and the destructor shall be accessible, even if the copy/move operation is elided ( [class.copy]). The copy constructor shall be accessible, and is odr-used (6.3 [basic.def.odr]), even if the copy operation is elided, or a move constructor used to construct the exception object.

  2. Alter 17.9.7 [propagation] p. 7 as follows:

    exception_ptr current_exception() noexcept;

    7 Returns: An exception_ptr object that refers to the currently handled exception (14.4 [except.handle]) or a copy of the currently handled exception, or a null exception_ptr object if no exception is being handled. The referenced object shall remain valid at least as long as there is an exception_ptr object that refers to it. If the function needs to allocate memory and the attempt fails, it returns an exception_ptr object that refers to an instance of bad_alloc. It is unspecified whether the return values of two successive calls to current_exception refer to the same exception object. [ Note: That is, it is unspecified whether current_exception creates a new copy each time it is called. — end note ] If the attempt to copy the current exception object throws an exception, or is otherwise not possible, the function returns an exception_ptr object that refers to the thrown exception if any or, if this is not possible, to an instance of bad_exception. [ Note: The copy constructor of the thrown exception may also fail, so the implementation is allowed to substitute a bad_exception object to avoid infinite recursion. — end note ]

  3. Alter 17.9.7 [propagation] p. 9 and add a new paragraph after p. 9 as follows:

    [[noreturn]] void rethrow_exception(exception_ptr p);

    8 Requires: p shall not be a null pointer.

    9 Throws: a copy of the exception object to which p refers, or any exception thrown by the attempt to copy the exception object to which p refers.

    ? Synchronization: Calls to rethrow_exception on exception_ptr objects that refer to the same exception object shall appear to occur in a single total order. The completion of each call shall synchronize with (6.9.2 [intro.multithread]) the next call in that total order.