Quote:Original post by Telastyn

Quote:Original post by Billr17
Because you cannot guarentee when the garbage collector will make a collection, you never want to fully rely on the destructor for cleanup.

And as an interesting note, .NET at least guarantees that the destructor will be called.

Java does not.

.NET:
"due to the non-deterministic nature of finalization the framework does not and cannot guarantee that the Finalize method will ever be called on an instance. Hence, you cannot rely upon this method to free up any un-managed resources (such as a file handle or a database connection instance) that would otherwise not be garbage collected by the GC."
-http://www.devx.com/dotnet/Article/33167/0/page/2

However in Java there's a sure-fire way to track object garbage collections using ReferenceQueues:
http://www.ibm.com/developerworks/java/library/j-refs/

Quote:Original post by Telastyn
C# spec, page 86. Any objects not yet garbage collected are finalized prior to application termination unless you explicitly suppress it.

To add to your statement :-)

The original link I provided about the Finalizer states:

Quote:
This method is automatically called after an object becomes inaccessible, unless the object has been exempted from finalization by a call to SuppressFinalize. During shutdown of an application domain, Finalize is automatically called on objects that are not exempt from finalization, even those that are still accessible. Finalize is automatically called only once on a given instance, unless the object is re-registered using a mechanism such as ReRegisterForFinalize and GC.SuppressFinalize has not been subsequently called.

Generally you would not call GC.SuppressFinalize on an object without good reason. In most cases it is only used in the Dispose methods. If Dispose is invoked manually, there should be no reason for the Finalizer to also attempt to release the same unmanaged resources. However, if something occurs where Dispose is never called, the Finalizer should be allowed to run. This scenario could occur if you are unable to make use of the C# using statement. For instance, you could have an object that must create a network connection and must remain opened. In this case, creating an object and disposing it within the same scope would be unsuitable.