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.
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
exception_ptr caught at the end of one thread could be safely
stored and rethrown in another thread - the original motivation for this
(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.
Change 17.9.7 [propagation]/7:
-7- Returns: An
exception_ptrobject that refers to the currently handled exception or a copy of the currently handled exception, or a null
exception_ptrobject if no exception is being handled. The referenced object remains valid at least as long as there is an
exception_ptrthat refers to it. If the function needs to allocate memory and the attempt fails, it returns an
exception_ptrobject that refers to an instance of
bad_alloc. It is unspecified whether the return values of two successive calls to
current_exceptionrefer to the same exception object. [Note: that is, it is unspecified whether
current_exceptioncreates a new copy each time it is called. --end note]