In C++ or No GC enviroment, we have two serious problems in windows programming.
- deletes other objects to which the object holds pointers
- closes handles to resource
And .NET cannot release unmanaged resource automatically. so .NET prepared Finalize() method to dipose unmanaged resource.
In VB.NET : actually write the Finalize() method
In C# : pseudo-destructor with the ~NameOfYourClass() -> C# Compiler creates the Finalized() method using the code when we write in the specialized pesudo-destructor.
Writing Finalize() is rarely a good idea
if you don't use unmanaged resource, Don't write the Finalize() method. It make inaccessible instances and delay the cleanup.
Releasing managed resources in Finalize() can wreak havoc
Don't access managed resources with in the Finalize() method. If you access managed resource, it cannot be predicted.
Also, don't call any methods on other objects, or even set their reference to null/Nothing.
Rules to invoke base.Finalize() aren't consistent
In VB.NET, you write Finalize() method as a protect method but you only write pseudo-destructor in C#.
so you don't invoke the base class's Finalize() method in C# but you must invoke the base class's Finalize() method in VB.NET.
Depending on the Finalize() can tie up critical resources
.NET provides a mechanism to support synchronous cleanup fo resource used by object. : IDisposable interface
If you want to clean up your unmanaged resource synchronously, you can write Dispose() method used IDisposable interface.
Using Finalize() on disposed objects is costly
It's better to Dispose() an object than to depend on Finalize() method because Dispose() let you control the clean up of an object.
and Dispose() should have already taken care of its resources, both managed and unmanaged resources.
Calling Finalize() on an object involves overhead. This should be avoided as mush as possible. From within your Dispose() method, call GC.SuppressFinalize().
