Why doesn't TransactionScope assume success?

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.

us开发者_高级运维ing(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.

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?

It means that you don't need to put a manual try/finally (or catch) block (possibly with a "success" flag) in for the failure case. Try rewriting the above code to roll back on error, and look at how much messier it is...

Basically the normal desired behaviour is to only commit if it reaches the end of the block with no exceptions. The simplest way of achieving that is to put a method call to signify success at the end of the block.

If the other implementation had been chosen, then people would be asking the converse question!

Seriously though, the default behaviour in a mechanism designed to protect against partial or incorrect updates surely has to be not to commit, doesn't it?

I think the amount of code to write for success is, as @Jon Skeet says, less (and less ugly) the current way. From a transaction point of view, however, I would think that you would want to be pessimistic and assume that unless success was explicitly indicated you would roll it back. Committing a transaction in error is a much worse problem, in my opinion, than accidentally failing to commit a successful transaction because of a code error.