Using the using-statement and pattern in C#


How often do find yourself writing code like this to do some things in batch:

    BatchCalculator calc = new BatchCalculator();
    calc.Suspend();
    calc.CalculateSomething(something);
    calc.CalculateSomethingElse(something);
    calc.Resume();

Well, I do and I’m not really happy about sprinkling those Suspends and Resumes around everywhere I need to start and stop something. I see at least two common pitfalls with thishttp://www.flickr.com/photos/stuckincustoms/894698437/ solution and a minor hiccup:

  1. Somewhere down the pipe I’m bound to forget the call to Resume explicitly and I’ll have a bug on my hands.
  2. Somewhere in between the Suspend and Resume calls an Exception is thrown, Resume is never reached, and leaving the object in an unwanted state.
  3. It could be better looking!  ->

The short using-introduction

With the introduction of .NET and it’s managed environment and non-deterministic garbage collector, there were several figureheads in the industry that raised an eyebrow or two. There were also people raising more than their eyebrows as well, and according to legend and several .NET Rocks shows, Chris Sells (now a blue badge) was one. They allegedly made MS include an IDisposable interface with a simple method Dispose() to fill their garbage collection needs. And if that wasn’t enough, they included the using-statement which is a try-finally in disguise where the finally automatically calls IDisposable.Dispose()!

A couple of regulars in my world in that department are the IDbConnection interface and later (from 2.0 and onwards) the TransactionScope class, but it has also been recommended practice for any implementers of the IDisposable interface.

Yeah yeah, but what can I do with it?

With the aforementioned background in place we can exploit it to create a better and more fluent API for our batch-oriented processes. Let us simply dive into the code, and I introduce without further ado; the changed BatchCalculator:

public class BatchCalculator
{
    public IDisposable Suspend(){}
    public void Resume(){}
    public void CalculateSomethingElse(object something){}
    public void CalculateSomething(object something){}
}

Suspend now returns an IDisposable and we can replace our calling code to this:

    BatchCalculator calc = new BatchCalculator();
    using(calc.Suspend())
    {
        calc.CalculateSomething(something);
        calc.CalculateSomethingElse(something);
    }

Yes! That’s more like it. I definitively like to looks of that.

But how.. do I ensure a call to Resume?

This is where the "magic" happens. Let us make a class which implements IDisposable that gets returned from our Suspend method:

public class Suspender : IDisposable
{
    private readonly BatchCalculator m_calculator;
 
    public Suspender(BatchCalculator calculator)
    {
        m_calculator = calculator;
    }
 
    public void Dispose()
    {
        m_calculator.Resume();
    }
}

And our revised Suspend method:

public IDisposable Suspend()
{
    return new Suspender(this);
}

Now go look at the implemented Dispose-method in our Suspender-class. It just calls our Resume method on our BatchCalculator! So when the using-block is exited, the Dispose-method is called and hooray, mission accomplished.

Finishing touch

To increase the applicability of the Suspender-class I introduce the role interface IResumable:

public interface IResumable
{
    void Resume();
}

And implement it in BatchCalculculator:

public class BatchCalculator : IResumable
{
    public IDisposable Suspend()
    {
        return new Suspender(this);
    }
    public void Resume(){}
    public void CalculateSomethingElse(object something){}
    public void CalculateSomething(object something){}
}

Now the Suspender class can just wrap our new interface:

public class Suspender : IDisposable
{
    private readonly IResumable m_resumable;
 
    public Suspender(IResumable resumable)
    {
        m_resumable = resumable;
    }
 
    public void Dispose()
    {
        m_resumable.Resume();
    }
}

Final note

If we revisit our weak spots, have we solved them all? A definitive yes; using using guarantees that the Dispose()-method is called which in turn calls our wrapped method. I must also add I really like the syntactic sugar using represents.

This pattern is obviously at a tangent for what using and IDisposable was supposed to be used for. The MSDN library has this to say about IDisposable:

The primary use of this interface is to release unmanaged resources.

But why not leverage what we have available. After all, coding is done once. Reading it is another matter completely.

  1. #1 by Fredrik on June 14th, 2008

    Great idea! :)

(will not be published)