100

Possible Duplicate:
How does one tell if an IDisposable object reference is disposed?

Is there a method to check if object has been disposed different then

try
{
    myObj.CallRandomMethod();
} catch (ObjectDisposedException e)
{
    // now I know object has been disposed
}

In my case I'm using TcpClient class that has Close() method which disposes object and this can happen in piece of code I don't have control of. In this case I would like to have better solution then catching exception.

Community
  • 1
  • 1
jethro
  • 18,177
  • 7
  • 46
  • 42
  • 3
    http://stackoverflow.com/questions/192206/how-does-one-tell-if-an-idisposable-object-reference-is-disposed – Iain Ward Aug 11 '10 at 10:55
  • I knew this issue in general is too common to not have Q&A on stackoverflow but I failed to search it. – jethro Aug 11 '10 at 12:01

4 Answers4

57

The reliable solution is catching the ObjectDisposedException.

The solution to write your overridden implementation of the Dispose method doesn't work, since there is a race condition between the thread calling Dispose method and the one accessing to the object: after having checked the hypothetic IsDisposed property , the object could be really disposed, throwing the exception all the same.

Another approach could be exposing a hypothetic event Disposed (like this), which is used to notify about the disposing object to every object interested, but this could be difficoult to plan depending on the software design.

Luca
  • 11,646
  • 11
  • 70
  • 125
  • 8
    Exceptions are supposed to handle exceptions, not become part of the infrastructure of the code. Using them is lazy and not what they are there for, which is why the original post explicitely asked for a reliable alternative. – user236800 Jan 20 '21 at 21:03
  • Should we blame the TcpSocket implementers for throwing unnecessary exceptions? The DisposedException is exceptional; the problem shouldn't be "handling exceptions", because the code does and you must accept it. Anyway – Luca Jun 24 '23 at 22:32
45

A good way is to derive from TcpClient and override the Disposing(bool) method:

class MyClient : TcpClient {
    public bool IsDead { get; set; }
    protected override void Dispose(bool disposing) {
        IsDead = true;
        base.Dispose(disposing);
    }
}

Which won't work if the other code created the instance. Then you'll have to do something desperate like using Reflection to get the value of the private m_CleanedUp member. Or catch the exception.

Frankly, none is this is likely to come to a very good end. You really did want to write to the TCP port. But you won't, that buggy code you can't control is now in control of your code. You've increased the impact of the bug. Talking to the owner of that code and working something out is by far the best solution.

EDIT: A reflection example:

using System.Reflection;
public static bool SocketIsDisposed(Socket s)
{
   BindingFlags bfIsDisposed = BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.GetProperty;
   // Retrieve a FieldInfo instance corresponding to the field
   PropertyInfo field = s.GetType().GetProperty("CleanedUp", bfIsDisposed);
   // Retrieve the value of the field, and cast as necessary
   return (bool)field.GetValue(s, null);
}
Plater
  • 105
  • 1
  • 5
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
19

If you're not sure whether the object has been disposed or not, you should call the Dispose method itself rather than methods such as Close. While the framework doesn't guarantee that the Dispose method must run without exceptions even if the object had previously been disposed, it's a common pattern and to my knowledge implemented on all disposable objects in the framework.

The typical pattern for Dispose, as per Microsoft:

public void Dispose() 
{
    Dispose(true);

    // Use SupressFinalize in case a subclass
    // of this type implements a finalizer.
    GC.SuppressFinalize(this);      
}

protected virtual void Dispose(bool disposing)
{
    // If you need thread safety, use a lock around these 
    // operations, as well as in your methods that use the resource.
    if (!_disposed)
    {
        if (disposing) {
            if (_resource != null)
                _resource.Dispose();
                Console.WriteLine("Object disposed.");
        }

        // Indicate that the instance has been disposed.
        _resource = null;
        _disposed = true;   
    }
}

Notice the check on _disposed. If you were to call a Dispose method implementing this pattern, you could call Dispose as many times as you wanted without hitting exceptions.

Ryan Brunner
  • 14,723
  • 1
  • 36
  • 52
  • 2
    This is not helpful. The member is private. – Hans Passant Aug 11 '10 at 11:07
  • Sorry, I may have misread your question. Are you looking to detect whether an object is disposed for reasons other than "should I dispose this object"? If so, why? Having unknown code potentially dispose objects seems like a leaky design. – Ryan Brunner Aug 11 '10 at 11:09
  • 4
    While the framework itself doesn't give any guarantees, the documentation for `IDisposable` says this: *"If an object's `Dispose` method is called more than once, the object must ignore all calls after the first one. The object must not throw an exception if its `Dispose` method is called multiple times. Instance methods other than `Dispose` can throw an `ObjectDisposedException` when resources are already disposed."* http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx – LukeH Aug 11 '10 at 11:23
  • 1
    @HansPassant: If an object implements `IDisposable`, one can call `(IDisposable.Dispose)` on it whether or not the object has a public member by that name. – supercat Jun 17 '12 at 12:46
-1

Best practice says to implement it by your own using local boolean field: http://www.niedermann.dk/2009/06/18/BestPracticeDisposePatternC.aspx

Boris Modylevsky
  • 3,029
  • 1
  • 26
  • 42