Re: [boost] [transact] Handling with user exceptions

Subject: Re: [boost] [transact] Handling with user exceptions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-07 08:46:13

----- Original Message ----- 
From: <strasser_at_[hidden]>
To: "vicente.botet" <vicente.botet_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Monday, March 01, 2010 11:39 PM
Subject: Re: [transact] Handling with user exceptions

> 
> Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> I would like to initiate a discussion on how to manage with user  
>> exceptions. Here follows some thougth I'm implementing in Boost.STM.
>>
>> There are two main ways to manage with user exceptions:
>> * exceptions commit transactions - corresponds to the current C++ behavior
>> * exceptions abort on exit - corresponds to rollback
> 
> I think we should look at this from the user's perspective first and  
> why he would use either of those ways to manage exceptions.
> 
> this guideline on exception safety can help us a lot in this I think:
> http://www.boost.org/community/exception_safety.html
> 
> by the definitions of section 3 there, transactions are nothing more  
> than a vehicle to achieve the "strong" exception guarantee.
> 
> using "exceptions commit transactions" by your definitino above (which  
> imho does not correspond to current c++ behaviour, if you follow  
> exception guidelines) would mean that you intentionally only use a  
> "basic" exception guarantee for a certain function/transaction scope.
> 
> why would that be desirable?
> as section 5 of david abrahams' paper notes, "From a client's  
> point-of-view, the strongest possible level of safety would be  
> ideal.", and then goes on with considerations on when to accept a  
> "basic" guarantee for performance reasons.
> 
> these don't apply for us, as we already impose the overhead described  
> in paragraph 2 on every operation.

I would make a difference between nested transactions and root transactions. 

* When a nested transaction throws a user exception the user can handle this exception between the root transaction and the nested transaction. The question is which state of the transaction will be the better to let the user to manage with the user exception? If the nested transaction is rollback the user is unable to know the state of the system when the exception was thrown. But if the transaction is commited, the user will have access to the state as it was when the exception was thrown. 

The fact that the functions including nested transactions doesn't satisfy even "The basic guarantee: that the invariants of the component are preserved, and no resources are leaked." it is not important as the action has not been commited completly, as only the root transaction will realize the visible commit.

* When a root transaction throws a user exception the user don't have any mean using the TM system to achieve a the "strong guarantee; that is, that the operation has either completed successfully or thrown an exception, leaving the program state exactly as it was before the operation started". In this case the rollback of the root transaction seems the best choice.

So instead of providing two family of macros we can have a default behavior that differes for root and nested transactions. If the implicit behavior is not desirable we will need two family of macros.

Hoping this explanation is enough to justify that we need to play with both behaviors before stating which one is the best default behavior: either user exceptions commit transactions or user exception abort on exit.

Best,
Vicente