- Title
- Exceptions thrown during coroutine startup
- Status
- open
- Section
- 9.5.4 [dcl.fct.def.coroutine]
- Submitter
- Tomasz KamiĆski
Created on 2022-04-06.00:00:00
last changed 33 months ago
Messages
Date: 2022-04-06.00:00:00
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.
|
Date |
User |
Action |
Args |
2022-04-06 00:00:00 | admin | create | |