Many parts of the operating system that are exposed to manage code through the framework class libraries are unmanaged. Such classes provide a Dispose or a Close method. File system objects and database connections (among others) utilize unmanaged resources and thus sport a Dispose method. Most objects in the FCL that sport a Dispose or Close method use unmanaged resource(s) internally which need to be deterministically cleaned up after they are no longer needed or from a finally code block in the event of an exception.
Cleaning up unmanaged resources and reclaiming managed memory are two separate and distinct activities. Cleaning up unmanaged resources is done with the Dispose or Close method and reclaiming managed memory is performed by the Garbage Collector automatically when an object is no longer reachable by code and irrespective of weather or not the Dispose method has been called. Objects that have been "disposed" can be resurrected if the garbage collector has not yet decided to reclaim their memory, and objects that have not had their Dispose method called can still be garbage collected and reclaimed once they become unreachable. It is important to note that due to the multi-generational nature of the garbage collector, if your application design allows your object to survive one garbage collection to become a second or third generation object -- then it stands an even higher potential for living much, much, longer than you might anticipate... perhaps even as long as your application remains running. It might not be wise to be too nonchalant about leaving more database connections open than necessary and trusting that the GC "in principal" will clean them up. These types of objects require deterministic finalization to work properly in any modest production application and they should be used that way. Please feel free to disagree as I don't want to be argumentative, but I do not believe that there is very much subjectivity in properly handling and disposing of managed and unmanaged objects. The topic can get complex, but the rules are very clear and the documentation is quite specific. I offer the following set of excellent Microsoft MSDN articles as examples: http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/ --Paul Mehner -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Good Sent: Tuesday, January 25, 2005 9:53 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Disposing of objects Unmanaged is one criterion, but there are others. Even managed resources, like database connections, should be handled sparingly. There is a somewhat subjective measure of 'heaviness' that should be applied, and I would suspect the great majority of your classes should not implement Idisposable. Essentially, you should only implement Idisposable on objects that need to _explicitly_ free subordinate resources at a deterministic time, or that cannot/should not wait for the garbage collector to come along. (In principle, the garbage collector _will_ come along and close open connections, but this is likely to leave far more open than are necessary). There is a nice discussion from MSFT on when to use Idispoable and Finalize here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht ml/cpconFinalizeDispose.asp. They recommmend The following rules outline the usage guidelines for the Dispose method: * Implement the dispose design pattern on a type that encapsulates resources that explicitly need to be freed. Users can free external resources by calling the public Dispose method. * Implement the dispose design pattern on a base type that commonly has derived types that hold on to resources, even if the base type does not. If the base type has a close method, often this indicates the need to implement Dispose. In such cases, do not implement a Finalize method on the base type. Finalize should be implemented in any derived types that introduce resources that require cleanup. * Free any disposable resources a type owns in its Dispose method. * After Dispose has been called on an instance, prevent the Finalize method from running by calling the GC.SuppressFinalize Method. The exception to this rule is the rare situation in which work must be done in Finalize that is not covered by Dispose. * Call the base class's Dispose method if it implements IDisposable. * Do not assume that Dispose will be called. Unmanaged resources owned by a type should also be released in a Finalize method in the event that Dispose is not called. * Throw an ObjectDisposedException from instance methods on this type (other than Dispose) when resources are already disposed. This rule does not apply to the Dispose method because it should be callable multiple times without throwing an exception. * Propagate the calls to Dispose through the hierarchy of base types. The Dispose method should free all resources held by this object and any object owned by this object. For example, you can create an object like a TextReader that holds onto a Stream and an Encoding, both of which are created by the TextReader without the user's knowledge. Furthermore, both the Stream and the Encoding can acquire external resources. When you call the Dispose method on the TextReader, it should in turn call Dispose on the Stream and the Encoding, causing them to release their external resources. * You should consider not allowing an object to be usable after its Dispose method has been called. Recreating an object that has already been disposed is a difficult pattern to implement. * Allow a Dispose method to be called more than once without throwing an exception. The method should do nothing after the first call. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Knowlton, Gerald F. Sent: Tuesday, January 25, 2005 11:37 AM To: [email protected] Subject: [ADVANCED-DOTNET] Disposing of objects Greetings: We are having somewhat of a lengthy discussion going on here regarding the disposing of objects. One camp wants to put the following code into all classes: Private Disposed as Boolean . . . Public sub Dispose() Implements IDisposable.Dispose Dispose(True) GC.Suppressfinalize(me) End sub Protected Sub Dispose(ByVal Disposing as Boolean) If Disposed then Exit Sub If Disposing then DisposeOfObjects End Sub Private Sub Dispose of Objects <object_name> = nothing End Sub While the other camp says it is not needed unless the class has unmanaged resources. Our question is; which would be the better practice? Best regards, Jerry ================================================================== All BWXT, Inc. Email communications are subject to auditing for adherence to company policy pertaining to waste, fraud and abuse. Misuse of the e-mail system is cause for disciplinary action. ================================================================== =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
