Question

Assuming this as the traditional Dispose pattern (taken from devx but seen on many websites)

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);
  }
}

I don’t understand why we call GC.SupressFinalize(this). This requires me to write my own managed resource disposal, including nulling my references? I’m a bit lost, I must admit. Could someone shed some light on this pattern?

Ideally, I would like to only dispose my unmanaged resources and let the GC do the managed collecting by itself.

Actually, I don’t even know why we specify a finalizer. In any case, the coder should call dispose himself, now shouldn’t he? If that’s just a fallback mechanism, I’d remove it.

Answer 1

The IDisposable pattern is used so that the object can clean up its resources deterministically, at the point when the Dispose method is called by the client code.

The finaliser is only there as a fallback in case the client code fails to call Dispose for some reason.

If the client code calls Dispose then the clean-up of resources is performed there-and-then and doesn’t need to be done again during finalisation. Calling SuppressFinalize in this situation means that the object no longer incurs the extra GC cost of finalisation.

And, if your own class only uses managed resources then a finaliser is completely unnecessary: The GC will take care of any managed resources, let those resources themselves worry about whether they need a fallback finaliser. You should only consider a finaliser in your own class if it directly handles unmanaged resources.