Hello,
This library seems very interresting. But you say that uncaught_exception_count() has flaws in your code. Can you give any exemple of the cases where your library can be fooled?
As far as I know, uncaught_exception_count itself does not have flaws. There is some flaw in unwinding_indicator based on uncaught_exception_count. It works as follows: 1. store uncaught_exception_count in constructor 2. member function unwinding() returns true if state stored in constructor does not equals to current uncaught_exception_count. I.e. returns true on transition of state. 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_... (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. 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. Thank you! Best Regards, Evgeny