Proposed resolution:

1. Alter [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 ([basic.def.odr]), even if the copy operation is elided, or a move constructor used to construct the exception object.

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

   exception_ptr current_exception() noexcept;
   

   7 Returns: An exception_ptr object that refers to the currently handled exception ([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 [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 ([intro.multithread]) the next call in that total order.

Rationale:

It would break too many existing implementations

[ 2011-03-23 Madrid meeting ]

No consensus for a change

[ 2011-03-15: Anthony drafts wording ]

[ Resolution suggested by NB comment ]

Add the following to 18.8.5, [propogation]

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

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.