This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 17.9.7 [propagation] Status: CD1 Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [propagation].
View all issues with CD1 status.
Discussion:
Without some lifetime guarantee, it is hard to know how this type can be used. Very specifically, I don't see how the current wording would guarantee and exception_ptr caught at the end of one thread could be safely stored and rethrown in another thread - the original motivation for this API.
(Peter Dimov agreed it should be clearer, maybe a non-normative note to explain?)
[ Bellevue: ]
Agree the issue is real.
Intent is lifetime is similar to a shared_ptr (and we might even want to consider explicitly saying that it is a shared_ptr< unspecified type >).
We expect that most implementations will use shared_ptr, and the standard should be clear that the exception_ptr type is intended to be something whose semantics are smart-pointer-like so that the user does not need to worry about lifetime management. We still need someone to draught those words - suggest emailing Peter Dimov.
Move to Open.
Proposed resolution:
Change 17.9.7 [propagation]/7:
-7- Returns: An exception_ptr object that refers to the currently handled exception or a copy of the currently handled exception, or a null exception_ptr object if no exception is being handled. The referenced object remains valid at least as long as there is an exception_ptr 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]