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.10.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.10.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.10.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.