On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote:
Hi Everyone,
It is my understanding that the reason scope_fail was left to die in the
C++ Extensions for Library Fundamentals v3 was that it is not
implementable.
I'm not sure what you mean in the "left to die" part. Do you mean that
these facilities are being deprecated?
One cannot detect if the scope is being left due to an
exception thrown from within the scope. Observing the number of uncaught
exceptions in the constructor and in the destructor will not work, given
that we now have coroutines that can be suspended and then resumed in
another thread (with a different number of uncaught exceptions), or even in
the same thread but at some later point, when the number of uncaught
exceptions has changed.
The enclosed example illustrates how a scope_fail fails to call the
callback when an exception is thrown from a coroutine. It uses Lewis
Baker's CppCoro implementation of a generator.
The only reliable way to call a callback when the scope is left due to an
exception is through using the explicit call to `deactivate()` function. It
is more verbose, but reliable.
I must say I have no experience with coroutines, but my understanding is
that they are basically incompatible with any mechanism that relies on
thread-specific state, including the uncaught exceptions counter. Thus I
wouldn't say scope_success/scope_fail are unimplementable - they clearly
are - but that they are incompatible with coroutines. That is, these
scope guards will work as expected as long as you don't switch
coroutines within the guarded scope.
I admit this is a notable limitation, and I will document it. But I do
not consider this limitation fatal, as there is plenty code out there
that doesn't use coroutines - I'd even say, much more code than that does.
Thanks for pointing this out.
Also, I forgot to mention that Boost.Scope's scope_success/scope_fail
support custom failure predicates which may not rely on the exception
state at all.
Andrey Semashev