Rob Stewart wrote:
strasser@uni-bremen.de wrote:
Zitat von "Stewart, Robert" <Robert.Stewart@sig.com>:
Couldn't you avoid the inner try block by detecting a pending exception in ~commit_on_destruction()?
because of how std::uncaught_exception() works that would fail if the macros are used inside a destructor that is called during exception unwinding:
I'm familiar with that issue, but I never imagined that would be a reasonable use case. Would you want to encourage using such code in a destructor by this design choice?
The question is not to encourage the use of such a code in a destructor. The code on the destructor can call a function that contains an inner transaction. Thus we have that this code can be executed on a destructor indirectly. Stephan, we shouldn't forget to add a test for this case. As we cannot throw an isolation_exception, we need to force the transaction to abort. Does this use case responds to the need for force_to_abort/set_rollback_only? Best, Vicente -- View this message in context: http://old.nabble.com/-transact--code-in-sandbox-tp27515535p27625796.html Sent from the Boost - Dev mailing list archive at Nabble.com.