I don't quite understand the workings of using/Disposable objects

I asked a question regarding returning a Disposable (IDisposable) object from a function, but I thought that I would muddle the discussion if I raised this question there.

I created some sample code:

class UsingTest
{
    public class Disposable : IDisposable
    {
        public void Dispose()
        {
            var i = 0;
            i++;
        }
    }
    public static Disposable GetDisposable(bool error)
    {
        var obj = new Disposable();
        if (error)
            throw new Exception("Error!");
        return obj;
    }
}

I coded it this way deliberately, because then I call:

using (var tmp = UsingTest.GetDisposable(true)) { }

Using the debugger, I notice that the Dispose method never executes, even though we've already instantiated a Disposable object. If I correctly understand the purpose of Dispose, if this class actually had opened handles and the like, then we would not close them as soon as we had finished with them.

I ask this question because this behavior aligns with what I would expect, but in the answers to the related question, people seemed to indicate that using would take care of everything.

If using still somehow takes care of all of this, could someone explain what I'm missing? But, if this code could indeed cause resource leak, how 开发者_StackOverflow中文版would you suggest I code GetDisposable (with the condition that I must instantiate the IDisposable object and run code which could throw an exception prior to the return statement)?

---

The reason it's never called is because of the way you allocate it. The "tmp" variable is never allocated at all, because the GetDisposable(bool) function never returns due to the fact that you threw an exception.

If you were to say instead the following,

using (var tmp = new Disposable())
{
    throw new ArgumentException("Blah");
}

then you would see that IDisposable::Dispose() does indeed get called.

The fundamental thing to understand is that the using block has to get a valid reference to the IDisposable object. If some exception occurs so that the variable declared in the using block does not get assigned then you are out of luck, because the using block will have no knowledge of the IDisposable object.

As for returning an IDisposable object from a function, you should use a standard catch block inside of the function to call Dispose() in the event of a failure, but obviously you should not use a using block because this will dispose the object before you are ready to do so yourself.

---

Depending upon what semantics you want for GetDisposable, this is probably how I would implement it:

public static Disposable GetDisposable(bool error)
{
    var obj = new Disposable();

    try
    {
        if (error)
            throw new Exception("Error!");

        return obj;
    }
    catch (Exception)
    {
        obj.Dispose();
        throw;
    }
}

---

This is because the tmp variable is never assigned. It's something you need to be careful of with disposable objects. A better definition for GewtDisposable would be:

public static Disposable GetDisposable(bool error)
{
    var obj = new Disposable();

    try
    {
        if (error)
            throw new Exception("Error!");
        return obj;
    }
    catch
    {
        obj.Dispose();
        throw;
    }
}

Because it ensures that obj is disposed.

---

The IDisposable interface simply guarantees that the class that implements it has a Dispose method. It does nothing in regard to calling this method. A using block will call Dispose on the object when the block is exited.

---

You create an IDisposable in GetDisposable but since you exit the function by throwing an exception, it never gets returned and hence tmp never gets assigned. The using statement is shorthand for

var tmp = UsingTest.GetDisposable(true);
try { }
finally
{
    if(tmp != null) tmp.Dispose();
}

and you never reach the try block. The solution in your example is to check the error flag before creating the disposable obj:

public static Disposable GetDisposable(bool error)
{
    if (error)
        throw new Exception("Error!");
    return new Disposable();
}

---

A related question is Handling iDisposable in failed initializer or constructor and I think the answer is that if you want to avoid leaking disposable objects from a failed constructor, you'll have to smuggle out a copy of the object from the constructor (e.g. stash it in a passed-in container, or assign it to a passed-by-reference variable) and wrap the constructor call in a catch block. Icky, but I don't know how to do it better. VB.net can actually manage a little better than C# because of how its initializers work.