Develop Reference

Disposable wrapped in a using statement, object is added to list but can still be accessed via the list from outside of the using statement. why? [duplicate]

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.WriteLine("{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.

Disposable Class

Please consider the following class:
public class Level : IDisposable
{
public Level() { }
public void Dispose() { }
}
My question is, if I call the Dispose method, will the class actually be disposed (garbage collected)?
ex:
Level level = new Level();
level.Dispose();
Thanks.

My question is, if I call the Dispose method, will the class actually be disposed?
If by disposed you mean garbage collected, then no, this won't happen. What will happen when you call the Dispose method is, well, the Dispose method be called and its body executed.
Also it is recommended to wrap disposable resources in a using statement to ensure that the Dispose method will always be called even in the event of an exception. So instead of manually calling it you could:
using (Level level = new Level())
{
// ... do something with the level
}
Normally the Dispose method is used when the object holds pointers to some unmanaged resources and provides a mechanism to deterministically release those resources.

I assume that what you are after is a way to know that Dispose() was called?
You can do that either in the consuming code by setting the instance to null after disposing:
Level level = new Level();
//do stuff with the instance..
level.Dispose();
level = null;
//in other place:
if (level != null)
{
//still available
}
Or in the class itself, add boolean flag and in every method check for it:
public class Level : IDisposable
{
private bool disposing = false;
public Level() { }
public void Foo()
{
if (disposing)
return;
MessageBox.Show("foo");
}
public void Dispose()
{
if (disposing)
return;
disposing = true;
}
}

Each class that implements IDisposable defines what it means to be disposed. By that line of reasoning, yes, your class will be as disposed as it wants to be.

No, the instance won't be garbage collected due to calling Dispose. The Dispose method is where you can release any resources held by the instance, it isn't about disposing the instance itself.

If you call Dispose() it will be disposed, which doesn't absolutely mean that it will be garbage collected,seems to me that is your question, if not please clarify.

In .NET Disposing and garbage collection are two different things:
The point of disposing is to release any resources that are either not managed by .NET (like manually allocated memory) or that have interests in being released as soon es they aren't needed anymore (like file handles or network connections).
The purpose of garbage collection is to free memory that is managed by .NET (like normal objects).
So, as others pointed out: your object will not necessarily be garbage collected when it gets disposed.

How to implement IDisposable properly

I've seen so much C# code in my time as a developer that attempt to help the GC along by setting variables to null or calling Dispose() on classes (DataSet for example) within thier own classes Dispose() method that
I've been wondering if there's any need to implement it in a managed environment.
Is this code a waste of time in its design pattern?
class MyClass : IDisposable
{
#region IDisposable Members
public void Dispose()
{
otherVariable = null;
if (dataSet != null)
{
dataSet.Dispose();
}
}
#endregion
}

The GC does not call .Dispose() (It does, however, call the finalize ~MyClass() method, which you can provide a call to the Dispose() method to have resources automatically managed when the GC decides to clean up your class).
You must always provide a way of disposing internal resources such as DataSets to code that uses your classes (and ensure you actually call .Dispose() or wrap the constructor in a using). Using IDisposable on your classes that use internal resources is highly recommended.
From MSDN:
The primary use of this interface is
to release unmanaged resources. The
garbage collector automatically
releases the memory allocated to a
managed object when that object is no
longer used. However, it is not
possible to predict when garbage
collection will occur. Furthermore,
the garbage collector has no knowledge
of unmanaged resources such as window
handles, or open files and streams.
public void Dispose()
{
otherVariable = null;
if (dataSet != null)
{
dataSet.Dispose();
dataSet = null;
}
}

No, Dispose methods are not a waste of time.
The dispose pattern is there to allow a caller to clean up a class as soon as they have finished with it, rather than waiting for the GC to collect it. The delay doesn't matter much for plain heap memory, which is why basic classes like String don't implement it. What Dispose is useful for however is cleaning up unmanaged resources. Somewhere internally, the Dataset class is using an unmanaged resource, so it provides a dispose method to allow you to let it know when that unmanaged resource can be released.
If the pattern has been followed correctly Dataset will also have a finalizer (or some subclass will) which means that if you didn't dispose of it manually, eventually the GC would run, the finalizer would get called and the unmanaged resource would be cleaned up that way. This unmanaged resource might be important though, imagine if it was a file lock, or a database connection, you don't really want to hang around waiting for the GC to run before you can reuse your database connection. Dispose provides a deterministic way of cleaning up resources when they are finished rather than relying on the non-deterministic GC.
As for setting variables to null in a dispose method. It nearly all cases it would be pointless. setting a variable to null removes a reference to that variable, which will make it eligible for garbage collection (if that's the last reference), but as you are disposing of the class anyway, you are likely to be going out of scope for the containing class so the internal class will become eligible for collection anyway.
If you have member variables inside your class that are disposable that you created (not just references you hold), then you should always call dispose on them from your own class's dispose method, but don't bother setting them to null.

Not entirely. If you have member variables which are disposable, then you probably should dispose of it like that. Your object may live longer than the scope of the work it is doing as the garbage collector is not guaranteed to run at any particular time.
Setting managed variables to null is a waste of time though. The object won't get GC'd any faster.

Garbage truck comes to my area every week but it doesn't collect my garbage unless I put my garbage bin in a way that it can collect.
You should simply remove all unwanted event subscriptions, reference and clear unmanaged handlers. Then Garbage Collector will take care of the rest.
Below example show the general best practice to implement IDisposable interface. Reference : https://msdn.microsoft.com/en-us/library/system.idisposable.dispose(v=vs.110).aspx
public class DisposeExample
{
// A base class that implements IDisposable.
// By implementing IDisposable, you are announcing that
// instances of this type allocate scarce resources.
public class MyResource: IDisposable
{
// Pointer to an external unmanaged resource.
private IntPtr handle;
// Other managed resource this class uses.
private Component component = new Component();
// Track whether Dispose has been called.
private bool disposed = false;
// The class constructor.
public MyResource(IntPtr handle)
{
this.handle = handle;
}
// Implement IDisposable.
// Do not make this method virtual.
// A derived class should not be able to override this method.
public void Dispose()
{
Dispose(true);
// This object will be cleaned up by the Dispose method.
// Therefore, you should call GC.SupressFinalize to
// take this object off the finalization queue
// and prevent finalization code for this object
// from executing a second time.
GC.SuppressFinalize(this);
}
// Dispose(bool disposing) executes in two distinct scenarios.
// If disposing equals true, the method has been called directly
// or indirectly by a user's code. Managed and unmanaged resources
// can be disposed.
// If disposing equals false, the method has been called by the
// runtime from inside the finalizer and you should not reference
// other objects. Only unmanaged resources can be disposed.
protected virtual void Dispose(bool disposing)
{
// Check to see if Dispose has already been called.
if(!this.disposed)
{
// If disposing equals true, dispose all managed
// and unmanaged resources.
if(disposing)
{
// Dispose managed resources.
component.Dispose();
}
// Call the appropriate methods to clean up
// unmanaged resources here.
// If disposing is false,
// only the following code is executed.
CloseHandle(handle);
handle = IntPtr.Zero;
// Note disposing has been done.
disposed = true;
}
}
// Use interop to call the method necessary
// to clean up the unmanaged resource.
[System.Runtime.InteropServices.DllImport("Kernel32")]
private extern static Boolean CloseHandle(IntPtr handle);
// Use C# destructor syntax for finalization code.
// This destructor will run only if the Dispose method
// does not get called.
// It gives your base class the opportunity to finalize.
// Do not provide destructors in types derived from this class.
~MyResource()
{
// Do not re-create Dispose clean-up code here.
// Calling Dispose(false) is optimal in terms of
// readability and maintainability.
Dispose(false);
}
}
public static void Main()
{
// Insert code here to create
// and use the MyResource object.
}
}

Why should we call SuppressFinalize when we don't have a destructor

I have few Question for which I am not able to get a proper answer .
1) Why should we call SuppressFinalize in the Dispose function when we don't have a destructor .
2) Dispose and finalize are used for freeing resources before the object is garbage collected. Whether it is managed or unmanaged resource we need to free it , then why we need a condition inside the dispose function , saying pass 'true' when we call this overridden function from IDisposable:Dispose and pass false when called from a finalize.
See the below code I copied from net.
class Test : IDisposable
{
private bool isDisposed = false;
~Test()
{
Dispose(false);
}
protected void Dispose(bool disposing)
{
if (disposing)
{
// Code to dispose the managed resources of the class
}
// Code to dispose the un-managed resources of the class
isDisposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
what if I remove the boolean protected Dispose function and implement the as below.
class Test : IDisposable
{
private bool isDisposed = false;
~Test()
{
Dispose();
}
public void Dispose()
{
// Code to dispose the managed resources of the class
// Code to dispose the un-managed resources of the class
isDisposed = true;
// Call this since we have a destructor . what if , if we don't have one
GC.SuppressFinalize(this);
}
}

I'm going out on a limb here, but... most people don't need the full-blown dispose pattern. It's designed to be solid in the face of having direct access to unmanaged resources (usually via IntPtr) and in the face of inheritance. Most of the time, neither of these is actually required.
If you're just holding a reference to something else which implements IDisposable, you almost certainly don't need a finalizer - whatever holds the resource directly is responsible for dealing with that. You can make do with something like this:
public sealed class Foo : IDisposable
{
private bool disposed;
private FileStream stream;
// Other code
public void Dispose()
{
if (disposed)
{
return;
}
stream.Dispose();
disposed = true;
}
}
Note that this isn't thread-safe, but that probably won't be a problem.
By not having to worry about the possibility of subclasses holding resources directly, you don't need to suppress the finalizer (because there isn't one) - and you don't need to provide a way of subclasses customising the disposal either. Life is simpler without inheritance.
If you do need to allow uncontrolled inheritance (i.e. you're not willing to bet that subclasses will have very particular needs) then you need to go for the full pattern.
Note that with SafeHandle from .NET 2.0, it's even rarer that you need your own finalizer than it was in .NET 1.1.
To address your point about why there's a disposing flag in the first place: if you're running within a finalizer, other objects you refer to may already have been finalized. You should let them clean up themselves, and you should only clean up the resources you directly own.

Here are the main facts
1) Object.Finalize is what your class overrides when it has a Finalizer. the ~TypeName() destructor method is just shorthand for 'override Finalize()' etc
2) You call GC.SuppressFinalize if you are disposing of resources in your Dispose method before finalization (i.e. when coming out of a using block etc). If you do not have a Finalizer, then you do not need to do this. If you have a Finalizer, this ensures that the object is taken off of the Finalization queue (so we dont dispose of stuff twice as the Finalizer usually calls the Dispose method as well)
3) You implement a Finalizer as a 'fail safe' mechanism. Finalizers are guaranteed to run (as long as the CLR isnt aborted), so they allow you to make sure code gets cleaned up in the event that the Dispose method was not called (maybe the programmer forgot to create the instance within a 'using' block etc.
4) Finalizers are expensive as Types that have finalizers cant be garbage collected in a Generation-0 collection (the most efficient), and are promoted to Generation-1 with a reference to them on the F-Reachable queue, so that they represent a GC root. it's not until the GC performs a Generation-1 collection that the finalizer gets called, and the resources are released - so implement finalizers only when very important - and make sure that objects that require Finalization are as small as possible - because all objects that can be reached by your finalizable object will be promoted to Generation-1 also.

Keep the first version, it is safer and is the correct implementation of the dispose pattern.
Calling SuppressFinalize tells the GC that you have done all the destruction/disposing yourself (of resources held by your class) and that it does not need to call the destructor.
You need the test in case the code using your class has already called dispose and you shouldn't tell the GC to dispose again.
See this MSDN document (Dispose methods should call SuppressFinalize).

1. Answer for the first question
Basically, you don't have to call SuppressFinalize method if your class doesn't have a finalize method (Destructor). I believe people call SupressFinalize even when there is no finalize method because of lack of knowledge.
2. Answer for the second question
Purpose of the Finalize method is to free un-managed resources. The most important thing to understand is that, Finalize method is called when the object is in the finalization queue. Garbage collector collects all the objects that can be destroy. Garbage Collector adds objects those have got finalization to the finalization queue before destroy. There is another .net background process to call the finalize method for the objects those are in the finalization queue. By the time that background process execute the finalize method, that particular object's other managed reference may have been destroyed. Because there is no specific order when it comes to the finalization execution. So, the Dispose Pattern wants to make sure that finalize method do not try to access managed objects. That's why managed objects are going in side "if (disposing)" clause which is unreachable for the finalize method.

You should always call SuppressFinalize() because you might have (or have in the future) a derived class that implements a Finalizer - in which case you need it.
Let's say you have a base class that doesn't have a Finalizer - and you decided not to call SuppressFinalize(). Then 3 months later you add a derived class that adds a Finalizer. It is likely that you will forget to go up to the base class and add a call to SuppressFinalize(). There is no harm in calling it if there is no finalizer.
My suggested IDisposable pattern is posted here: How to properly implement the Dispose Pattern

Disposing objects in the Destructor

I have an object that has a disposable object as a member.
public class MyClass
{
private MyDisposableMember member;
public DoSomething
{
using (member = new MyDisposableMember())
{
// Blah...
}
}
}
There can be many methods in MyClass, all requiring a using statement. But what if I did this instead?
public class MyClass
{
private MyDisposableMember member = new MyDisposableMember();
public DoSomething
{
// Do things with member :)
}
~MyClass()
{
member.Dispose();
}
}
As you can see, member is being disposed in the destructor. Would this work? Are there any problems with this approach?

Ideally, Dispose() should have already been called prior to finalization. It would be better to follow the typical dispose pattern, and allow the user to Dispose() the object properly, and have the finalizer Dispose of it if dispose has not already been called.
In this case, since you're encapsulating an IDisposable, you really don't need to implement the finalizer at all, though. (At the the point of finalization, your encapsulated member will get finalized, so there's no need to finalize your object - it just adds overhead.) For details, read this blog article I wrote on encapsulating an IDisposable.

You should probably make MyClass implement IDisposable. Inside the Dispose() method, call member.Dispose();. That way the programmer can have control over when the member gets disposed.

DO NOT DO THAT!
The GC will do that for you (indirectly as the object to dispose or another one will contain a destructor)
MyDisposableMember might even be disposed by the GC even before you dispose it - what happens then might not be what you intended to do.
Even worse: Adding a destructor (or finalizer) to a class costs additional time when disposing of the object (much more time as the object will stay in memory for at least one collection cyclus and maybe even promoted to the next generation).
Therfore, it would be completely useless and even backfire.

In your first example the member is not really part of the object's state since you're instantiating it every time it's used and disposing it right after. Since it's not part of the state don't model it as such just use a local variable when needed.
In more general you should put all disposal logic in Dispose() and implement IDisposable then use you class together with using or try-finally

The only thing I see wrong (and it isn't an error) is the fact that in a using statement you explicitly dispose of the object at that point in time (when your function / method is called). The destructor cannot be called they are invoked automatically. So at this point it may take some time for member to be disposed of. Better to implement the IDisposeable interface for MyClass.

Following the Microsoft pattern is your best bet so the users of your class have full control over when it is disposed.
public class MyClass : IDisposable
{
private MyDisposableMember member = new MyDisposableMember();
public DoSomething
{
// Do things with member :)
}
~MyClass()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing) // Release managed resources
{
member.Dispose();
}
// Release unmanaged resources
}
}

When a finalizer runs, one of the following will be true about almost any IDisposable object to which it holds a reference:
The object will have already had its finalizer run, in which case calling Dispose on the object will be at best useless.
The object will not have had its finalizer run, but its finalizer will be scheduled to run, so calling Dispose on the object will be useless.
The object will still be in use by something other than the object being finalized, so calling Dispose on it would be bad.
There are a few situations where calling Dispose in a finalizer might be useful, but most situations fit the cases listed above, which all have a common feature: the finalizer shouldn't call Dispose.