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.
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:
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.
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]) ora 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 ]
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.