I respectfully disagree that 3 is the most important option. The reason for the finalizer is to ensure that unmanaged resources get cleaned up even if the developer using the object forgets or is too lazy to call Dispose and/or an exception in his or her code causes the calling of an object's Dispose method to not occur. The finalizer will clean up the unmanaged resources when the object itself is destroyed.
The fact is that very few classes need any dispose pattern at all. Those classes that do need a dispose code pattern need to use option 2. --Paul Mehner -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ian Griffiths Sent: Wednesday, January 26, 2005 3:43 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Disposing of objects One thing that's worth making clear is that for any given class you have three choices: (1) Don't implement IDisposable at all (2) Implement the Dispose pattern you've shown here (or something like it) (3) Implement IDisposable, but don't have a finalizer Because the docs focus so heavily on the dispose pattern (option 2), it's not uncommon for people who are new to this not to realise the (3) is even an option. This is unfortunate because, as it happens, it's often the most important option. It's certainly appropriate more often than (2). The fact is that very few classes need the full dispose pattern. Specifically, the finalization stuff is only required if your class *directly* manages raw handles, or handle-like things. (E.g., anything represented as an IntPtr.) Most classes don't actually wrap raw handles directly. But *lots* of classes wrap them indirectly. If you're wrapping other objects that implement IDisposable (such as a SqlConnection), then you too should implement IDisposable, but there's no need to have a finalizer. (So that would be option 3 above.) You seem to be proposing option 2 on *all* classes. Option 2 should in fact be the least common - for most classes, either 1 or 3 will be more appropriate. So I'd say definitely *don't* implement that pattern you've shown on all classes. Microsoft seem to push 2 too heavily. For example, as someone else pointed out, they say: "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." If you take this literally, it includes things like SqlConnection and FileStream - those need to be freed explicitly with a call to Close or Dispose. You really don't need the full Dispose pattern (i.e., with a finalizer and two Dispose methods) in that case. And that's the most common case, so it's a shame they tell you to use the full Dispose pattern... The fact is that there's nothing useful you can do to such resources in your finalizer. -- Ian Griffiths - DevelopMentor http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: Knowlton, Gerald F. > > 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 DevelopMentor(r) 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
