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 <boost-users-bounces@lists.boost.org> On Behalf Of Oliver Kowalke via Boost-users
Sent: Monday, December 17, 2018 13:47
To: boost-users <boost-users@lists.boost.org>
Cc: Oliver Kowalke <oliver.kowalke@gmail.com>
Subject: Re: [Boost-users] Understanding fibers

Unfortunately, I can’t help you with fibers: I’ve went with coroutines https://www.boost.org/doc/libs/1_68_0/doc/html/boost_asio/overview/core/spawn.html not the least because it seems (! – I have to test this, I don’t fully trust the documentation on this) that exceptions can propagate nicely out of a coroutine handler and to the top-level event loop. According to the documentation, this isn’t the case for fibers, if an unhandled exception propagates out of the fiber’s stack frame, the program is terminated.

boost.coroutine(2) and boost.fiber are base on boost.context - exceptions can be transported between different contexts. boost.fiber is modeled after std::thread -> if you use fiber::future<> you get the exceptions propagated from the fiber.