Why disposed object doesn't throw exception on using it after disposing?

Is it legal to call a method on disposed object? If yes, why?

In the following demo program, I've a disposable class A (which implements IDisposable interface).As far as I know, if I pass disposable object to using() construct, then Dispose() method gets called automatically at the closing bracket:

A a = new A();
using (a)
{
   //...
}//<--------- a.Dispose() gets called here!

//here the object is supposed to be disposed, 
//and shouldn't be used, as far as I understand.

If that is correct, then please explain the output of this program:

public class A : IDisposable
{
   int i = 100;
   public void Dispose()
   {
      Console.WriteLine("Dispose() called");
   }
   public void f()
   {
      Console.Writ开发者_Python百科eLine("{0}", i); i  *= 2;
   }
}

public class Test
{
        public static void Main()
        {
                A a = new A();
                Console.WriteLine("Before using()");
                a.f();
                using ( a) 
                {
                    Console.WriteLine("Inside using()");
                    a.f();
                }
                Console.WriteLine("After using()");
                a.f();
        }
}

Output (ideone):

Before using()
100
Inside using()
200
Dispose() called
After using()
400

How can I call f() on the disposed object a? Is this allowed? If yes, then why? If no, then why the above program doesn't give exception at runtime?

---

I know that the popular construct of using using is this:

using (A a = new A())
{
   //working with a
}

But I'm just experimenting, that is why I wrote it differently.

---

Disposed doesn't mean gone. Disposed only means that any unmanaged resource (like a file, connection of any kind, ...) has been released. While this usually means that the object doesn't provide any useful functionality, there might still be methods that don't depend on that unmanaged resource and still work as usual.

The Disposing mechanism exist as .net (and inheritly, C#.net) is a garbage-collected environment, meaning you aren't responsable for memory management. However, the garbage collector can't decide if an unmanaged resource has been finished using, thus you need to do this yourself.

If you want methods to throw an exception after the object has been diposed, you'll need a boolean to capture the dispose status, and once the object is disposed, you throw the exception:

public class A : IDisposable
{
   int i = 100;
   bool disposed = false;
   public void Dispose()
   {
      disposed = true;
      Console.WriteLine("Dispose() called");
   }
   public void f()
   {
      if(disposed)
        throw new ObjectDisposedException();

      Console.WriteLine("{0}", i); i  *= 2;
   }
}

---

The exception is not thrown because you have not designed the methods to throw ObjectDisposedException after Dispose has been called.

The clr does not automagically know that it should throw ObjectDisposedException once Dispose is called. It's your responsibility to throw an exception if Dispose has released any resources needed for successful execution of your methods.

---

A typical Dispose() implementation only calls Dispose() on any objects that it stores in its fields that are disposable. Which in turn release unmanaged resources. If you implement IDisposable and not actually do anything, like you did in your snippet, then the object state doesn't change at all. Nothing can go wrong. Don't mix up disposal with finalization.

---

The purpose of IDisposable is to allow an object to fix the state of any outside entities which have, for its benefit, been put into a state that is less than ideal for other purposes. For example, an Io.Ports.SerialPort object might have changed the state of a serial port from "available for any application that wants it" to "only usable by one particular Io.Ports.SerialPort object"; the primary purpose of SerialPort.Dispose is to restore the state of the serial port to "available for any application".

Of course, once an object that implements IDisposable has reset entities that had been maintaining a certain state for its benefit, it will no longer have the benefit of those entities' maintained state. For example, once the state of the serial port has been set to "available for any application", the data streams with which it had been associated can no longer be used to send and receive data. If an object could function normally without outside entities being put into a special state for its benefit, there would be no reason to leave outside entities in a special state in the first place.

Generally, after IDisposable.Dispose has been called on an object, the object should not be expected to be capable of doing much. Attempting to use most methods on such an object would indicate a bug; if a method can't reasonably be expected to work, the proper way to indicate that is via ObjectDisposedException.

Microsoft suggests that nearly all methods on an object which implements IDisposable should throw ObjectDisposedException if they are used on an object which has been disposed. I would suggest that such advice is overbroad. It is often very useful for devices to expose methods or properties to find out what happened while the object was alive. Although one could give a communications class a Close method as well as a Dispose method, and only allow one to query things like NumberOfPacketsExchanged after a close but not after a Dispose, but that seems excessively complicated. Reading properties related to things that happened before an object was Disposed seems a perfectly reasonable pattern.

---

Calling Dispose() doesn't set the object reference to null, and your custom disposable class doesn't contain any logic to throw an exception if its functions are accessed after Dispose() has been called so it is of course legal.

In the real world, Dispose() releases unmanaged resources and those resources will be unavailable thereafter, and/or the class author has it throw ObjectDisposedException if you try to use the object after calling Dispose(). Typically a class-level boolean would be set to true within the body of Dispose() and that value checked in the other members of the class before they do any work, with the exception being thrown if the bool is true.

---

A disposer in C# is not the same as a destructor in C++. A disposer is used to release managed (or unmanaged) resources while the object remains valid.

Exceptions are thrown depending on the implementation of the class. If f() does not require the use of your already disposed objects, then it doesn't necessarily need to throw an exception.