This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-04-18


828. Destruction of exception objects

Section: 14.2  [except.throw]     Status: CD2     Submitter: UK     Date: 3 March, 2009

N2800 comment UK 130

[Voted into WP at March, 2010 meeting.]

14.2 [except.throw] paragraph 4 says,

When the last remaining active handler for the exception exits by any means other than throw; the temporary object is destroyed and the implementation may deallocate the memory for the temporary object...

With std::current_exception() (17.9.7 [propagation] paragraph 7) , it might be possible to refer to the exception object after its last handler exits (if the exception object is not copied). The text needs to be updated to allow for that possibility.

Proposed resolution (September, 2009):

Change 14.2 [except.throw] paragraph 4 as follows:

The memory for the temporary copy of the exception being thrown exception object is allocated in an unspecified way, except as noted in 6.7.5.5.2 [basic.stc.dynamic.allocation]. The temporary persists as long as there is a handler being executed for that exception. In particular, if If a handler exits by executing a throw; statement, that passes control rethrowing, control is passed to another handler for the same exception, so the temporary remains. The exception object is destroyed after either When the last remaining active handler for the exception exits by any means other than throw; rethrowing, or the last object of type std::exception_ptr (17.9.7 [propagation]) that refers to the exception object is destroyed, whichever is later. In the former case, the destruction occurs when the handler exits, immediately after the destruction of the object declared in the exception-declaration in the handler, if any. In the latter case, the destruction occurs before the destructor of std::exception_ptr returns. the temporary object is destroyed and the The implementation may then deallocate the memory for the temporary exception object; any such deallocation is done in an unspecified way. The destruction occurs immediately after the destruction of the object declared in the exception-declaration in the handler.