Why does the traditional Dispose pattern suppress finalize?

Question

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

class Test : IDisposable
{
  private bool isDisposed = false;

          


        

Answer 1

The SuppressFinalize call exists in case some derived class decides to add a finalizer. If a normal dispose completes successfully, finalization won't be necessary; even if a derived class decides to add one, the SuppressFinalize call will prevent it from executing and interfering with garbage collection.

To understand why this is important, you should think of finalization not as being part of garbage collection, but rather something that happens before it. When a class registers for finalization (automatic on creation, if it overrides Finalize) it is put into a special list called the Finalization Queue. No object in the Finalization Queue, nor any object referenced directly or indirectly by an object in the queue, can be garbage-collected, but if any object in the finalization queue is found to have no rooted references other than from the queue, the object will be pulled from the queue and the finalizer will run. While the finalizer is being dispatched, the object will not be collectable (since a reference will exist during the dispatch); once the finalizer is complete, there will usually not be any references to the object anymore, so it (and objects referenced thereby) will usually be collectable.

Personally, I think the SuppressFinalize is silly, since I can think of no good reason why a derived class should ever have a finalizer. If a derived class is going to add souse unmanaged resources(*) which the parent class will know nothing about, another class should be created for the purpose of holding those resources; the parent class should hold a reference to that. That way, the parent class itself will not need finalization, and objects which are referenced by the parent class won't be needlessly blocked from garbage collection.