I think there are a few short-comings in your argument. 1. A very clear differentiation between generic unmanaged resources and specific unmanaged resources need to be made (these are my terms - if there are other established or better terms, I'll happily comply). Specific resources, like handles to a particular file, should never be GC managed. Having a file that is sometimes locked and sometimes not, and might be released soon, is horrible behaviour, and would really look flaky from an external perspective. Generic but finite resources (DB connections, GDI objects) can be successfully managed by the GC, and are managed this way inside the Framework Library - the Handle Collector pattern inside Windows.Forms triggers a GC when the count of certain GDI objects gets too high.
2. The GC only cares about memory. It will happily let me run out of DB connections, and never trigger a collection, even if triggering a collection could free some DB connections to satisfy my request. You can leverage the GC to managed your non-memory resources like Windows.Forms does, but you have to explicitly equate a cost and maximum pool size to your resource, and manually trigger a GC accordingly. The possibility of someone else grabbing a reference to a resources that you later dispose is a problem, but they will receive an ObjectDisposedException when they attempt to use the resources, which can instantly diagnose the problem. So I guess its like in Win32 when functions documented certain memory pointers as being invalid after certain calls, but instead of having the hard-to-detect access of previously freed memory problems of Win32, an exception is generated. We lived pretty successfully with the Win32 dramas, and Dispose is an improvement on them, so I don't foresee large-scale problems caused by Dispose. Nick Wienholt Sydney Deep .NET User Group www.sdnug.org ----- Original Message ----- From: "Jesse Liberty" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 29, 2002 11:08 PM Subject: [ADVANCED-DOTNET] When to use IDispose > I'd like to open a discussion of when to use IDispose (a quick search of the > archives shows that this has not been discussed recently). > > It is my theory that this idiom will be vastly overused. > > I'll start by quoting Richter: "In general, I strongly discourage the use of > calling a Dispose or Close method...When application code calls Dispose or > Close it is effectively saying that it knows when the application no longer > has a need for the object. For many applications, it is impossible to know > for sure when an object is no longer required." (Richter, chapter 19, > Applied Microsoft .NET Framework Programming (Microsoft Press, 2002). > > It is his last sentence that I want to pick up on and discuss. I suspect > that > > (a) the ability of the GC to do the job is greatly underestimated and > (b) the need to use close is therefore greatly overestimated while > (c) the risk of calling Dispose is greatly underestimated > > It seems to me that if your object is (or might be) passed to ANY method > calling Close is very risky. You simply can't know if other objects have a > reference to it, and you certainly don't want to keep track. The only place > it does make sense to me to use this idiom is when > > a) the object is created in a very controlled situation (a single method) > and does not leave that method > b) the object contains a very limited resource > c) you know when you are done with the object > d) you are making a LOT of instances > > In any case, I write all this to spark conversation on this issue. > > Thanks. > ------------------------------- > Jesse Liberty, President > Liberty Associates, Inc. > .NET Programming and Training > http://www.LibertyAssociates.com > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
