Why doesn't TransactionScope assume success?

Question

The TransactionScope expects a call to its Complete method as follows. Otherwise the transaction will not be committed.

using(TransactionScope scope = new TransactionScope())
{
    /* Perform transactional work here */

    scope.Complete();
}

Wouldn't an implementation that assumes success have been more appropriate? This would mean that less code would be required in the standard case (success).

In the case of an exception or a call to a method such as 'Rollback' (this method does not currently exist) the transaction could be rolled back.

using(TransactionScope scope = new TransactionScope())
{
    /* Perform transactional work here */

     if(problemOccurred)
     {
         scope.Rollback();
     }
}

Note that the problemOccurred flag would only be required in cases where the problem did not result in an exception. In this case, the rollback would be performed automatically.

I am interested in gaining further insight into why this implementation was used.

Update: A couple of the answers so far argued that a try-catch block would be required if the implementation that I described were used. This is not the case. The transaction is automatically rolled back when an exception is not handled within the using block. This is the case in both the existing implementation and the one that I described. See 'Completing a transaction scope' section here for further details.

Update 2: I finally understand what was being explained in the answers. This is not a language construct that could have been interpreted any way that the language designers saw fit - it is an implementation of the IDisposable pattern. Without the call to Complete the code within the Dispose method would have no knowledge of whether it is being called as the result of the code within the using block being executed successfully or because an exception occurred. I was imagining something similar to the following where both transaction and rollback are keywords.

transaction
{
    /* Perform transactional work here */

     if(problemOccurred)
     {
         rollback;
     }
}

This would of course present problems if transaction options need to be passed to the TransactionScope.

Why isn't my comment automatically added when I change page, I shouldn't have to click [Add Comment]... — cjk
From update - The mechanism by which the transaction is rolled back in the face of exceptions is that you reach the end of the using block without calling Commit. I.e. that behaviour depends on the exact feature you want to remove. — Damien_The_Unbeliever
Your update is wrong - the only reason it currently rolls back is exactly the behavior you are complaining about. It assumes failure - if an exception occurs, Complete() is never called and thus the transaction fails. There is no other magic mechanism at work catching the exceptions. — Sander
@Scott - try implementing this yourself - all you have to do is implement a class that implements IDisposable, and inside the Dispose method, you have to determine whether you're being disposed as a result of an exception being propagated - and you'll realise why it won't work. — Damien_The_Unbeliever
Thanks Damien. I was thinking of TransactionScope as a language construct that could have been interpreted in any way that the language designers decided but it is nothing more than an implementation of IDisposable. — Scott Munro

Stefan Steinegger Stefan Steinegger · Accepted Answer · 2010-01-04T13:18:07

This way, every transaction would look like this:

using(TransactionScope scope = new TransactionScope())
{
  try
  {
    /* Perform transactional work here */
  }
  catch (Exception)
  {
    scope.Rollback();
    throw;
  }
}

Which is more code.

Edit:

Everything else is risky or bad style. You have to be absolutely sure that there wasn't any error when committing. When leaving the using block, you don't know if you leave it because an exception is thrown or because you just reached the end of it. When calling Complete, you know.

The transaction block syntax is already the simplest you can do. Just implement the transaction without any special error handling and commit it at the end. You don't have to care and rolling back when any error occurs. Consider, exceptions can be thrown in almost every single line of code (eg. NullReference, Overflows, InvalidOperation etc). So what could be easier than this?

Why doesn't TransactionScope assume success?

4 Answers