views:

306

answers:

4

I was reading this article the other day and was wondering why there was a Finalizer along with the Dispose method. I read here on SO as to why you might want to add Dispose to the Finalizer. My curiousity is, when would the Finalizer be called over the Dispose method itself? Is there a code example or is it based on something happening on the system the software is running? If so, what could happen to not have the Dispose method run by the GC.

+4  A: 

The purpose of the finaliser here is simply a safety precaution against memory leaks (if you happen not to call Dispose explicitly). It also means you don't have to dispose your objects if you want them to release resources when the program shutdowns, since the GC will be forced to finalise and collect all objects anyway.

As a related point, it is important to dispose the object slightly differently when doing so from the finaliser.

~MyClass()
{
    Dispose(false);
}

public void Dispose()
{
    Dispose(true);
    GC.SuppressFinalize(this);
}

protected void Dispose(disposing)
{
    if (!this.disposed)
    {
        if (disposing)
        {
            // Dispose managed resources here.
        }
        // Dispose unmanaged resources here.
    }
    this.disposed = true;
}

The reason you do not want to dispose managed resources in your finaliser is that you would actually be creating strong references to them in doing so, and this could prevent the GC from doing it's job properly and collecting them. Unmanaged resources (e.g. Win32 handles and such) should always be explicitly closed/disposed, of course, since the CLR has no knowledge of them.

Noldorin
And another reason not to dispose of managed resources in your finaliser... It's possible that they might have already been GC'd by the time your finaliser is executed. Trying to dispose them when they've already been collected would cause a runtime error.
LukeH
@Luke: True, but that can be avoided easily enough by setting all your references to null and then doing a null check before disposing.
Noldorin
@Noldorin - Where would unregistering of events fall in your example? I understand techincally they would fall under managed, but what if we had some object tied to this class through an event and we dont unregister it in the unmanaged part (assuming the user doesnt call Dispose directly and its left up to the GC to clean it up). Would it be safe/ok to put event unregistering in the managed section to make sure that happens? The side effect could be someone thinks they are Disposing an object, but really it never gets Disposed because of the event link between this class and the other.
SwDevMan81
@SwDevMan81: I understand the source of your concern, but really events are no different to other resources (they're in fact just wrappers around multicast delegates). Nonetheless, event unregistration belongs in the managed block of the `Dispose` method. Consider that if it is the finaliser calling the `Dispose` method, you can guarantee that events will be unregistered immediately by the GC as part of finalisation.
Noldorin
+3  A: 

This is mostly there to protect yourself. You cannot dictate what the end user of your class will do. By providing a finalizer in addition to a Dispose method, the GC will "Dispose" of your object, freeing your resources appropriately, even if the user forgets to call Dispose() or mis-uses your class.

Reed Copsey
It's worth mentioning that the GC is non-deterministic, so there's no guarantee of when, *or even if*, your finaliser will be called.
LukeH
Yes - If your program runs long enough, your object is most likely to get finalized. Also, if it shuts down cleanly, it'll get finalized. But there are no guarantees with the GC - which is part of why IDisposable exists in the first place.
Reed Copsey
A: 

The dispose method must be explicitly called, either by calling Dispose() or by having the object in a using statement. The GC will always call the finalizer, so if there is something that needs to happen before the objects are disposed of the finalizer should at least check to make sure that everything in the object is cleaned up.

You want to avoid cleaning up objects in the finalizer if at all possible, because it causes extra work compared to disposing them before hand (like calling dispose), but you should always at least check in the finalizer if there are objects lying around that need to be removed.

Kevin
+1  A: 

The Finalizer is called when the object is garbage collected. Dispose needs to be explicitly called. In the following code the finalizer will be called but the Dispose method is not.

class Foo : IDisposable
{
  public void Dispose()
  {
    Console.WriteLine("Disposed");
  }

  ~Foo()
  {
    Console.WriteLine("Finalized");
  }
}

...

public void Go()
{
  Foo foo = new Foo();
}
Wolfbyte
That is not entirely true. The finalizer is called some time after the object would otherwise be eligible for garbage collection (i.e. the application no longer references the instance). However, as the finalizer must be run for the instance, the CLR actually roots the object and thus it is not garbage collected until the finalizer has run.
Brian Rasmussen
There's also no guarantee that an object will *ever* be GC'd or that its finalizer will *ever* be called. That's why it's doubly important to ensure that you dispose of any `IDisposable` objects correctly.
LukeH