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

2024-12-19

2562. Exceptions thrown during coroutine startup

Subclause 9.5.4 [dcl.fct.def.coroutine] seems to miss specification about the behavior of coroutines when an exception is thrown during the early phases of a coroutine evaluation. It is unclear at what point the ownership of the coroutine frame is passed from the compiler to the user, who then needs to call std::coroutine_handle::destroy to destroy and free the coroutine frame, including the parameter copies. The following situations arise:

• Allocation fails, and get_return_object_on_allocation_failure() is returned.
• Allocation succeeds, but an exception is thrown before the return object is initialized (e.g. when initializing the promise or evaluating get_return_object). The coroutine state ought to be deallocated automatically and the exception propagated.
• The return object is successfully initialized, but an exception would leave the coroutine before it would first suspend, either because initial-suspend's await_ready or await_suspend exits via an exception, or because unhandled_exception rethrows. The coroutine ought to be suspended at its final suspend point, the return object destroyed, and the exception propagated; the return object's destructor is responsible for ensuring the coroutine is destroyed.
• The coroutine ever suspends, or the coroutine terminates normally without ever suspending. The return object is returned to the caller, carrying with it ownership of the coroutine state.

See also issue 2451.