
Hi, I could you please clarify in more detail what you just wrote?
Asio uses coroutine V1 which documentation implies that transportation of exceptions across contexts is automatic, notably ctor/operator() throwing an exception originating on “the other end” of the asymmetric coroutine pair. This seems to also be implied by the following warning in the documentation: “Code executed by coroutine-function must not prevent the propagation of the detail::forced_unwind exception. Absorbing that exception will cause stack unwinding to fail. Thus, any code that catches all exceptions must re-throw any pending detail::forced_unwind exception.”
On the other hand, the documentation for boost context has the following comment: “If the function executed inside a execution_context emits ans exception, the application is terminated by calling std::terminate(). std::exception_ptr can be used to transfer exceptions between different execution contexts.” This seems to imply that the execution context is standalone and if an exception propagates, the process is hosed.
So, in the context of asio, say we have
1. Coroutine … something_async(yield[ec]);
2. Fiber … something(ec);
If (ec) throw std::runtime_error(“”);
called from the io service loop. There is no catch in the above piece of code. What happens when:
1. The above is inside a _coroutine_ and invoked as a callback? (my guess: the caller – asio thread – arranges/provides a catch context that the exception propagates into)
2. The above is inside a _fiber_ and called by yielding to the fiber scheduler? (my guess: the fiber scheduler does not provide an outer catch context, so the program crashes).
Is this correct?
From: Boost-users