It can be fooled in following case: when object is created during stack unwinding (i.e. in some destructor), and that object outlived unwinding process, for instance it was stored in global variable. I have just added example to repo showing such case: https://github.com/panaseleus/**stack_unwinding/blob/master/** examples/uncaught_exception_**count_floating_object.cpp<https://github.com/panaseleus/stack_unwinding/blob/master/examples/uncaught_exception_count_floating_object.cpp>(it has output at bottom) . As you can see there is transition in uncaught_exception_count state, butdestructor ( ~ExpCountPrinter() ) is not called due to unwinding.
Thank you, i understand better now.
However, despite of this flaw, scope(failure) and scope(success) features can be reliably implemented on top of such unwinding_indicator, because it's objects live only in code blocks (compound-statements), and can't leave them. Especially in case of proposed BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS - user even don't see auxiliary variables.
i'll test it further.. But i think that this should be included in boost. Maybe this library could be added to boost by submitting a patch to scope_exit library? or by requesting a mini-review? thank you very much for your work. ecyrbe