Re: [scope] scope_fail is unimplementable

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-07 10:19:02

On 4/7/23 00:51, Andrey Semashev wrote:
> 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.