Intercepting an exception inside IDisposable.Dispose

Question

In the IDisposable.Dispose method is there a way to figure out if an exception is being thrown?

using (MyWrapper wrapper = new MyWrapper())
{
           


        

Answer 1

Instead of the syntactic sugar of the using statement, why not just implement your own logic for this. Something like:

try
{
  MyWrapper wrapper = new MyWrapper();

}
catch (Exception e)
{
  wrapper.CaughtException = true;
}
finally
{
   if (wrapper != null)
   {
      wrapper.Dispose();
   }
}

Answer 2

It is not possible to capture the Exception in the Dispose() method.

However, it is possible to check Marshal.GetExceptionCode() in the Dispose to detect if an Exception did occur, but I wouldn't rely on that.

If you don't need a class and want just want to capture the Exception, you can create a function that accepts a lambda that is executed within a try/catch block, something like this:

HandleException(() => {
    throw new Exception("Bad error.");
});

public static void HandleException(Action code)
{
    try
    {
        if (code != null)
            code.Invoke();
    }
    catch
    {
        Console.WriteLine("Error handling");
        throw;
    }
}

As example, You can use a method that automatically does a Commit() or Rollback() of a transaction and do some logging. At this way you don't always need a try/catch block.

public static int? GetFerrariId()
{
    using (var connection = new SqlConnection("..."))
    {
        connection.Open();
        using (var transaction = connection.BeginTransaction())
        {
            return HandleTranaction(transaction, () =>
            {
                using (var command = connection.CreateCommand())
                {
                    command.Transaction = transaction;
                    command.CommandText = "SELECT CarID FROM Cars WHERE Brand = 'Ferrari'";
                    return (int?)command.ExecuteScalar();
                }
            });
        }
    }
}

public static T HandleTranaction<T>(IDbTransaction transaction, Func<T> code)
{
    try
    {
        var result = code != null ? code.Invoke() : default(T);
        transaction.Commit();
        return result;
    }
    catch
    {
        transaction.Rollback();
        throw;
    }
}

Answer 3

This will catch exceptions thrown either directly or inside the dispose method:

try
{
    using (MyWrapper wrapper = new MyWrapper())
    {
        throw new MyException("Bad error.");
    }
}
catch ( MyException myex ) {
    //deal with your exception
}
catch ( Exception ex ) {
    //any other exception thrown by either
    //MyWrapper..ctor() or MyWrapper.Dispose()
}

But this is relying on them using this this code - it sounds like you want MyWrapper to do that instead.

The using statement is just to make sure that Dispose always gets called. It's really doing this:

MyWrapper wrapper;
try
{
    wrapper = new MyWrapper();
}
finally {
    if( wrapper != null )
        wrapper.Dispose();
}

It sounds like what you want is:

MyWrapper wrapper;
try
{
    wrapper = new MyWrapper();
}
finally {
    try{
        if( wrapper != null )
            wrapper.Dispose();
    }
    catch {
        //only errors thrown by disposal
    }
}

I would suggest dealing with this in your implementation of Dispose - you should handle any issues during Disposal anyway.

If you're tying up some resource where you need users of your API to free it in some way consider having a Close() method. Your dispose should call it too (if it hasn't been already) but users of your API could also call it themselves if they needed finer control.

Answer 4

James, All wrapper can do is log it's own exceptions. You can't force the consumer of wrapper to log their own exceptions. That's not what IDisposable is for. IDisposable is meant for semi-deterministic release of resources for an object. Writing correct IDisposable code is not trivial.

In fact, the consumer of the class isn't even required to call your classes dispose method, nor are they required to use a using block, so it all rather breaks down.

If you look at it from the point of view of the wrapper class, why should it care that it was present inside a using block and there was an exception? What knowledge does that bring? Is it a security risk to have 3rd party code privy to exception details and stack trace? What can wrapper do if there is a divide-by-zero in a calculation?

The only way to log exceptions, irrespective of IDisposable, is try-catch and then to re-throw in the catch.

try
{
    // code that may cause exceptions.
}
catch( Exception ex )
{
   LogExceptionSomewhere(ex);
   throw;
}
finally
{
    // CLR always tries to execute finally blocks
}

---

You mention you're creating an external API. You would have to wrap every call at your API's public boundary with try-catch in order to log that the exception came from your code.

If you're writing a public API then you really ought to read Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Microsoft .NET Development Series) - 2nd Edition .. 1st Edition.

---

While I don't advocate them, I have seen IDisposable used for other interesting patterns:

1. Auto-rollback transaction semantics. The transaction class would rollback the transaction on Dispose if not already committed.
2. Timed code blocks for logging. During object creation a timestamp was recorded, and on Dispose the TimeSpan was calculated and a log event was written.

* These patterns can be achieved with another layer of indirection and anonymous delegates easily and without having to overload IDisposable semantics. The important note is that your IDisposable wrapper is useless if you or a team member forget to use it properly.

Answer 5

No, there is no way to do this in the .Net framework, you cannot figure out the current-exception-which-is-being-thrown in a finally clause.

See this post on my blog, for a comparison with a similar pattern in Ruby, it highlights the gaps I think exist with the IDisposable pattern.

Ayende has a trick that will allow you to detect an exception happened, however, it will not tell you which exception it was.

Answer 6

If you want to stay purely within .net, two approaches I would suggest would be writing a "try-catch-finally" wrapper, which would accept delegates for the different parts, or else writing a "using-style" wrapper, which accept a method to be invoked, along with one or more IDisposable objects which should be disposed after it completes.

A "using-style" wrapper could handle the disposal in a try-catch block and, if any exceptions are thrown in disposal, either wrap them in a CleanupFailureException which would hold the disposal failures as well as any exception that occurred in the main delegate, or else add something to the exception's "Data" property with the original exception. I would favor wrapping things in a CleanupFailureException, since an exception that occurs during cleanup will generally indicate a much bigger problem than one which occurs in main-line processing; further, a CleanupFailureException could be written to include multiple nested exceptions (if there are 'n' IDisposable objects, there could be n+1 nested exceptions: one from the mainline and one from each Dispose).

A "try-catch-finally" wrapper written in vb.net, while callable from C#, could include some features that are otherwise unavailable in C#, including the ability to expand it to a "try-filter-catch-fault-finally" block, where the "filter" code would be executed before the stack is unwound from an exception and determine whether the exception should be caught, the "fault" block would contain code that would only run if an exception occurred, but would not actually catch it, and both the "fault" and "finally" blocks would receive parameters indicating both what exception (if any) occurred during the execution of the "try", and whether the "try" completed successfully (note, btw, that it would be possible for the exception parameter to be non-null even if the mainline completes; pure C# code couldn't detect such a condition, but the vb.net wrapper could).