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())
{
  throw new Exception("Bad error.");
}

If an exception is thrown in the using statement I want to know about it when the IDisposable object is disposed.

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

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.

Answer 3

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 4

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 5

Take a look at this from ayende http://ayende.com/Blog/archive/2007/06/20/Did-you-know-Find-out-if-an-exception-was-thrown.aspx