Add standard way to detect/handle exceptions raised from using(){} block.

[dmitriyse]

Most popular scenario is transactions:

using (var t = new MyTransaction())
{
    throw SomeThingGoesWrongException();
}
// -----------------
public class MyTransaction: IDisposable
{
    private void Commit()    {   ...    }
    private void RollBack()    {   ...    }
    public void Dispose()
    { 
          // Magic example:
          // bool isInException = Marshal.GetExceptionPointers() != IntPtr.Zero
          //              || Marshal.GetExceptionCode() != 0;

          if (!__Magic__.WasExceptionThrown)
          {
                Commit();
          }
         else
         {
               Rollback();
         }
         // Close DB context (for example)
    }
}

Exception detection from using block is very very wanted by millions of developers.
This problem is very old:
http://stackoverflow.com/questions/2830073/detecting-a-dispose-from-an-exception-inside-using-block

Please consider the next improvement to using block pseudo code:

// code in the head of using block
IDisposable disposable = new SomeDisposable();
try
{
    // Code inside using block.
}
catch(Exception ex)
{
   (disposable as IAbortable)?.OnException(ex);
   throw;
}
finally{
   disposable.Dispose();
}

public interface IAbortable: IDisposable
{
     void OnException(Exception ex);
}

For IAbortable objects wrapped by using block - new behavior should be performed:
when using block is exited due to exception - IAbortable.OnException should be called.

That's all. Simply to implement, powerful, beautiful.

[YaakovDavis]

catch(){}

This is a very nasty piece of generated code. The compiler shouldn't hide any exceptions, unless explicitly told to do so.
Now, if OnException does throw an error, should the original error (from within the using block), or the one from OnException be re-thrown?

Error-handling logic is typically maintained by the consumer a resource, not the resource itself. I don't see why transactions, or any other resource, for that matter, should handle exceptions. They have no intrinsic knowledge of the semantic meaning of an exception in the context in which they're being used.

[dmitriyse]

1. Yes, you are right. Good point.
2. Here not always. If you are framwork writer. Problem raiser and using-block handler (ICancellable) can be from one library/subsystem and knowledge about exception is very usable. For example when write to DB was abadoned by network error, Dispose with Rollback should not try to do send rollback over network.

[YaakovDavis]

write to DB was abandoned by network error

But the transaction implementation doesn't know that. It only receives an exception instance, without access to its meaning in that given application.
You might suggest that it'll check the Exception type, but this is unreliable. There might be countless scenarios which are uncovered by this type-check.
Such a feature will encourage writing erratic resources that consume errors in unexpected ways.

BTW, naming wise, I'll call it IAbortable to better communicate the use-case you're referring to.

[dmitriyse]

I am not agree with you. We are not talking about .Net BCL transaction. Most framework have it's own transaction implementation and again, a raiser and an using-block handler can be from a single library even from a single operation/workflow.

[dmitriyse]

IAbortable - good name! Thanks.

[ViIvanov]

Why not trying to explicitly call Commit() inside a using block? In this case in a Dispose() we explicitly know - committed transaction or not (was Commit() called or not) and can Rollback() transaction in case it not committed.

[dmitriyse]

Simple answer - verbosity.
If it is transactions and DB access, the 70+ % of cases uses commit as last operator.
And rest 30% are good fitted in this proposal.
There are different examples not only transactions and DB.

So it is general instrumentation that breaks nothing and allow framework developers to solve problems faster end robust.

Following you logic:

1. we can even avoid using block at all and always write try{}catch{}finally{}

[ViIvanov]

@dmitriyse Yes,

70+ % of cases uses commit as last operator

and this is OK. Calling a Commit() can take a lot of times and this is vary good that we have explicit Commit() call in our code instead of implicit closed brace (from using).

Also, Commit() can throw an exception and this is not good practice when exception thrown from a Dispose() method, because this method can be called implicitly from using statement.

[dmitriyse]

If you like explicit Commit(), please use it. IAbortable does not restrict you from this logic. Also I agree that in 30% of DB code cases should be implemented with explicit Commit() possibly with try catch logic inside using.

There are also cases where explicit Commit() and IAbortable should be used together.
Again this is not DB best practice talk.

This proposal is not for "Best DB practices" but about additional Feature to C# language that will helps to Framework developers to solve very complicated tasks, probably you will never facing with them.
Just skip this thread if you are work with only DB cases.

[dmitriyse]

In general, conceptually is nothing bad that using handler object will kwnow what was happened inside using block.

There are tons of code like that

 someVar.SomeOperation(()=>
   {
    // Do something that can rise error
   });

and SomeOperation analyzes what was happened inside provided Action.

for example Unit Tests frameworks can benefits from IAbortable

using (assert.Throw<MyException>("Only my exception should be raised"))
{
     int a = 0;
     Console.WriteLine(123/ a);
}

[dmitriyse]

Probably this proposal should be merged with #85

[ViIvanov]

@dmitriyse Can you please provide something other scenario for proposed feature, that does not related to the database transactions? In which kind of types you want to implement IAbortable?

[dmitriyse]

After C# 8.0 release, I have revisited using operator improvements and created new proposal which is superset for this one. See, #3025