I couldn't agree more, and was about to type this myself when I finally got caught up and found your reply. I can't imagine what all these people are doing that they find dispose+finalize to be the majority of the cases. Having instance fields that are disposable should be the vast majority over actually holding raw unmanaged resources as instance fields.
Russ -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Zaslavskiy, Dmitriy (IT) Sent: Wednesday, January 26, 2005 11:45 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Disposing of objects I don't even think those cases are rare. I think they should be the majority of cases. As Ian (and others) said you only want finalizer when you deal with raw handles/memory directly. For handles you should use SafeHandle/CriticalHandle and memory should wrapped into small classes (that have finalizers). That's it. All the rest can implement disposable pattern but not finalizer -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Eric Gunnerson Sent: Wednesday, January 26, 2005 12:19 PM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Disposing of objects I disagree that you would always want a finalizer. There are some cases - rare, perhaps - where your object contains an object that is disposable and finalizable, and in these cases, you might want to be disposable, but you would not want to be finalizable, since the finalizer on the contained object would handle that cleanup. The difference is that finalization can happen on any object, but dispose can only happen on the user-visible object. Eric -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Julian Everett Sent: Wednesday, January 26, 2005 4:12 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Disposing of objects If I understand what you say correctly, I think there's a non-obvious point to expand on here. Common sense would suggest that if you need a Dispose() method then you should implement a finaliser too, to perform the same clean-up in the instance that Dispose() is not called explicitly. In other words you should always choose (2) over (3). However, the problem arises because Finalizable objects are finalised in a non-deterministic manner. As a result, if you try to call a method on a non-static Finalizable type (e.g. sqlConnection.Dispose()) from within a finaliser and there is any chance the referenced object could be in the same finalisation object graph, then the referenced object might well have been finalised already - which would result in an exception being thrown. That's why you can do nothing useful to wrapped resources from within a finaliser, at least as I understand it. cheers Julian -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of Ian Griffiths Sent: 26 January 2005 11:43 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(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp IMPORTANT NOTICE This communication contains information, which is confidential and may also be privileged. It is for the exclusive use of the intended recipients(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender. The opinions expressed within this communication are not necessarily those expressed by Teletext Ltd. Teletext Ltd. Building 10 Chiswick Park 566 Chiswick High Road London W4 5TS Registered in England number 2694814 _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp =================================== 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(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. =================================== 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
