One of the big problems and a source of very difficult to find bugs in modern applications is resource, specifically Memory Management. The topic of dynamic memory allocation and de-allocation in languages such as C++ has required a great deal of thought both at the design and implementation level. Programs would create objects then leave them created through the life of the application and hope that the OS itself would tidy everything up. Although this sometimes works it more often than not created problems of so called Memory Leaks. As an alternative scenario, the application would create and use an object, then quite correctly delete it but the programmer would then try and use it again leading to run time errors such as Reference to Invalid memory Pointer ! .VB5/6 trapped the run time errors quite well and required error handlers to avoid application crash, C++ on the other hand can mask such problems since pointer values to invalid objects looked quite realistic so execution continued and the normal Garbage In -> Process -> Garbage Out continued until the whole application failed.
Although such mistakes are obvious when you find them, the debug process is quite painful, to create the problem you probably need to follow a specific route in the code, also the garbage value in a pointer may change for each debug session making it difficult to find the cause.
Some modern languages such as VB and Java have tried to side step the problem by the so called Create and Forget automatic memory management.In VB6 for instance you can create objects and then ignore the dispose totally, in most cases!
The .NET framework has taken this philosophy into all the Supported Languages by building in automatic garbage collection into the CLR.This is accomplished by the concept that an object created in a Supported Languages identifies itself by the reference returned to the application and its resources are allocated from a so called Managed Heap Then at regular intervals!, (up to this time I have not been able to get a better definition of collection time than regular intervals), a system thread examines all objects in the managed heap space to see which still have a valid reference in a running application. If all the references to a particular object have been removed then it is marked as garbage. and is subsequently removed from the managed heap and the memory returned to the available pool. Once all this collection is completed the objects remaining are compacted to create the largest free space on the managed heap for future allocation needs.
Considering the two problems highlighted above.
The only problem with such a technique is the whole created in the 'OO' model, all objects in the 'OO' model will have a destructor that the application can use to tidy up the object as they are deleted. We have to consider what used to be done in the destructor, the saving of serialised information and the destruction of object used within the object. The second of these is handled by the automatic garbage collection anyway, the first simply requires a re think of the objects initial design, there is normally some other event which can trigger the storage.
As an added feature the CLR Automatic Garbage collector does have a method called finalizer that is called on the objects final destruction during garbage collection. However, as Pratt in his book "Introducing Microsoft .NET" highlights you need to read the article in November & December 2000 Issues of MSDN magazine by J.Richters .NET Garbage & Finalizers before attempting to over ride the standard methods.