Using 'Using' for things other than resource disposal [duplicate]

Question

This question already has answers here:

Is it abusive to use IDisposable and "using" as a means for getting "scoped behavior" for exception safety? (12 answers)

Closed 9 years ago.

We all know that the using statement is really good for resources you want to cleanup in a timely manner, such as an open file or database connection.

I was wondering if it would be considered a good thing to use the statement in cases where resources cleanup isn't the goal of the Dispose() method, but rather resetting to a previous state.

For example, a class that allows a using statement to wrap a procedure that takes a noticeable amount of time and changes the Cursor to a waiting state.

class CursorHelper : IDisposable
{
   readonly Cursor _previousState;
   public CursorHelper(Cursor newState)
   {
      _previousState = Cursor.Current;
      Cursor.Current = newState;
   }

   public void Dispose()
   {
      Cursor.Current = _previousState;
   }
}

Then the class can be used as such, without worrying about reverting the Cursor when your are done.

public void TimeIntensiveMethod()
{
   using (CursorHelper ch = new CursorHelper(Cursors.WaitCursor))
   {
      // something that takes a long time to complete
   }
}

Is this an appropriate use of the using statement?

Answer 1

There are certainly precedents for (ab)using the using statement in this way, for example FormExtensions.BeginForm in the ASP.NET MVC framework. This renders a <form> closing tag when it's disposed, and it's main purpose is to enable a more terse syntax in MVC views. The Dispose method attempts to render the closing tag even if an exception is thrown, which is slightly odd: if an exception is thrown while rendering a form, you probably don't want to attempt to render the end tag.

Another example is the (now deprecated) NDC.Push method in the log4net framework, which returns an IDisposable whose purpose is to pop the context.

Some purists would say it's an abuse, I suggest you form your own judgement on a case-by-case basis. Personally I don't see anything wrong with your example for rendering an hourglass cursor.

The discussion linked in a comment by @I4V has some interesting opinions - including arguments against this type of "abuse" from the ubiquitous Jon Skeet.

Answer 2

In reality using is simply syntactical sugar for try/finally, so why don't you just do plain old try/finally like below...

try
{
    // do some work
}
finally
{
    // reset to some previous state
}

imho implementing the Dispose method to reset to some state would be very misleading, especially if you have consumers for your code.

Answer 3

I am opposed to this and believe it to be an abuse. I also think that RAII in C++ is a terrible idea. I am aware that I am in a minority on both positions.

This question is a duplicate. For detailed reasons on why I think this is an unwarranted abuse of the using statement, see: https://stackoverflow.com/a/2103158/88656

Answer 4

No, it isn't appropriate use of using and/or Dispose. The pattern has a very clear use ("Defines a method to release allocated resources."), and this isn't it. Any future developers using this code would look upon it with the contempt warranted for such evil.

If you want this kind of behaviour then implement events and expose them, calling code can subscribe to them and manage the cursor, if needs be, otherwise the cursor should be manageable by general parameters and maybe using Begin and End methods (although such naming conventions are generally reserved for asynchronous implementations of methods, you get the picture) - hacking this way doesn't actually buy you anything.

Answer 5

I my opinion it makes sense to use using-Disposable thing in a way other than just disposing objects. Of course it depends on the context and usage. If leads to a more readable code then it is ok.

I have had used it in a unit of work & repository pattern implementation like:

public class UnitOfWork: IDisposable  {
    // this is thread-safe in actual implementation
    private static Stack<UnitOfWork> _uowStack = new Stack<UnitOfWork>();
    public static UnitOfWork Current {get { return _uowStack.Peek(); }} 

    public UnitOfWork() {
        _uowStack.Push(this);
    }

    public void Dispose() {
        _ouwStack.Pop();
    }

    public void SaveChanges() {
        // do some db operations
    }
}

public class Repository {
    public void DoSomething(Entity entity) {
        // Do Some db operations         

        UnitOfWork.Current.SaveChanges();
    }
}

With this implementation it is guaranteed that nested operations will use their corresponding UnitOfWork without passing parameter. Usage is like.

using (new UnitOfWork()) 
{
    var repo1 = new UserRepository();
    // Do some user operation

    using (new UnitOfWork())  
    {
         var repo2 = new AccountingRepository();
         // do some accounting
    }

    var repo3 = new CrmRepository();
    // do some crm operations
}

In this sample repo1 and repo3 use the same UnitOfWork while repo2 uses a different repository. What reader reads is "using new unit of work" and it makes a lot of sense.