This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
exception_ptr?Section: 17.9.7[propagation]Status:CD1Submitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [propagation].
View all issues withCD1 status.
Discussion:
Without some lifetime guarantee, it is hard to know how this type can beused. Very specifically, I don't see how the current wording wouldguarantee andexception_ptr caught at the end of one thread could be safelystored and rethrown in another thread - the original motivation for thisAPI.
(Peter Dimov agreed it should be clearer, maybe a non-normative note toexplain?)
[Bellevue:]
Agree the issue is real.
Intent is lifetime is similar to a shared_ptr (and we might even want toconsider explicitly saying that it is a shared_ptr< unspecified type >).
We expect that most implementations will use shared_ptr, and thestandard should be clear that the exception_ptr type is intended to besomething whose semantics are smart-pointer-like so that the user doesnot need to worry about lifetime management. We still need someone todraught those words - suggest emailing Peter Dimov.
Move to Open.
Proposed resolution:
Change 17.9.7[propagation]/7:
-7- Returns: An
exception_ptrobject that refers to the currentlyhandled exception or a copy of the currently handled exception, or anullexception_ptrobject if no exception is being handled.The referenced object remains valid at least as long as there is anexception_ptrthat refers to it.If the function needs to allocate memory and the attemptfails, it returns anexception_ptrobject that refers to an instance ofbad_alloc. It is unspecified whether the return values of two successivecalls tocurrent_exceptionrefer to the same exception object. [Note:that is, it is unspecified whethercurrent_exceptioncreates a new copyeach time it is called.--end note]