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.