The Very Handy "Using" Statement

I’ve lost count how many times I had to refactor code that looks like this:

SqlConnection conn = new SqlConnection (...);
SqlCommand cmd = new SqlCommand (...);
// ... 
conn.Open();
cmd.ExecuteNonQuery ();
// ...

I rejoice if such code has conn.Close() at the end. What happens if an exception is thrown in ExecuteNonQuery(), for example? Your database connection stays open for a while because, well, nothing closed it. Keep doing this, and you exhaust SQL Server’s connection pool. Besides leaking resources, your application becomes unresponsive.

There’s an easy way out: the using statement (MSDN):

using (SqlConnection conn = new SqlConnection (...))
using (SqlCommand cmd = new SqlCommand (...))
{
    // ... 
    conn.Open();
    cmd.ExecuteNonQuery ();
    // ... 
}

The code above expands into something like this (“note the extra curly braces to create the limited scope for the object”):

{
    SqlConnection conn = new SqlConnection (...);
    try 
    {
        SqlCommand cmd = new SqlCommand (...);
        try 
        {
            conn.Open();
            cmd.ExecuteNonQuery();
        }
        finally 
        {
          if (cmd != null)
              cmd.Dispose ();
        }
    }
    finally 
    {
      if (conn != null)
          conn.Dispose ();
    }
}

In other words, you get a try-finally block for free. You still end up with an exception (notice the lack of catch there?), but the finally clause is guaranteed to dispose of expensive resources properly.

Naturally, this trick works only with classes which implement IDisposable. However, IDisposable comes with a lot of baggage, so don’t rush to implement it all over the place.

As a side benefit, calling Dispose() on SqlConnection also closes it.

To me, this is unwelcome coupling because it exposes me to the inner workings of the SqlConnection class—something I shouldn’t worry about. If I call a method, thinking, “Oh, and it also calls Xxxxx() inside”, I see it as bad API design.

A neat trick

Here’s a neat trick I picked up from Bill Wagner’s More Effective C#. Look at this code:

public void GetThingsDone ()
{
  T driver = new T();
  using (driver as IDisposable)
  {
     driver.DoWork();
  }
}

In Bill’s words:

The compiler creates a hidden local variable that stores a reference to the driver cast as an IDisposable. If T does not implement IDisposable, then the value of the local variable is null. In those cases, the compiler does not call Dispose(), because it checks against null before doing extra work. However, in all cases where T implements IDisposable, the compiler generates a call to the Dispose() method upon exiting the using block.

We saw the null check in finally above, but the interesting point here is that if a soft cast of IDisposable produces a null, the compiler just bails. Pretty cool!