Re: Need explanation on calling Close() from finalizer.

From: Ken Varn (nospam)
Date: 11/23/04 

Date: Tue, 23 Nov 2004 16:37:02 -0500

I understand the idea behind memory management of the GC. What I don't
understand is why .NET classes cannot clean up their unmanaged resources
themselves when they are collected through their destructor methods (or
finalizers, whatever they are called). Classes in C++ implement destructors
to do cleanup when they go out of scope. The user of any objects
instantiated from that class do not have to explicitly call a cleanup
methods of that object. The object does cleanup on its own when it is
destroyed.

Thus, I don't understand why .NET classes that require cleanup of unmanaged
resources need an IDisposable interface that the user must explicitly call
before the object is garbage collected. Why not just put it in a destructor
or finalize and have the GC call it? Maybe this is already done, but I
don't understand why there is always an emphasis to call Dispose() on
objects such as a SQLConnection(), when it should do it on its own when it
is finalized. 

-- 
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
-----------------------------------
""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message
news:eqpsugZ0EHA.2544@cpmsftngxa10.phx.gbl...
> Hi Ken
>
> NET's Garbage Collector, like you've stated, automated memory management,
relieving the developer of the need to explicitly delete objects.  What the
GC does not do (nor
> has it ever claimed to do) is clean up unmanaged resources (database
collections, file handles, etc).  The developer must explicitly clean up
these resources, usually through
> the Dispose pattern.   Note, calling Dispose is only necessary if an
object holds unmanaged resources.
>
> Hope that makes sense
> -Chris
>
> --------------------
>
> >
> >This is the one area about .NET that sort of bothers me.
> >
> >In C++, destructors work very well for cleaning up an object so that the
> >consumer of the object does not have to be concerned with doing cleanup.
> >Hence, in the spirit of .NET, garbage collection is what makes this
> >philosophy even more positive by automating memory management.  However,
> >because of the way garbage collection is done in .NET, it now cancels out
> >the destructor philosophy of object cleanup being up to the object
itself.
> >It now places that role back onto the object consumer and thus removes a
> >layer of encapsulation.  If an object consumer does not remember to call
a
> >Dispose() method, it could impact the application's ability to run
> >effectively.  For C++ programmers, this is equivalent to having to call
> >delete after newing an object (the exact thing that garbage collection
was
> >intended to prevent).  But instead of having to delete an object, the
> >consumer must now have to call Dispose().  Seems like the GC solution
solved
> >one problem, but created another.
> >
> >Don't want to sound like a .NET basher.  I use it a lot and love it.
> >However, there are some parts of it that seem like a step backward.
Maybe I
> >am over complicating this.  If anyone has further input on the subject, I
> >would appreciate some comments.
> >
> >
> >
> >-- 
> >-----------------------------------
> >Ken Varn
> >Senior Software Engineer
> >Diebold Inc.
> >
> >EmailID = varnk
> >Domain = Diebold.com
> >-----------------------------------
> >"John M Deal" <johndeal@necessitysoftware.com> wrote in message
> >news:elYd7b%23yEHA.1256@TK2MSFTNGP10.phx.gbl...
> >> I'm not a C++ guy but my guess is its because there is no deterministic
> >> finalization in .Net due to the garbage collector so you can't rely on
> >> when it will get called.  If you want this type of functionality I'd
> >> implement the IDisposable interface and place the "just in case" close
> >> of a connection in the dispose method and call that if necessary from
> >> your finalizer.  This allows the user of your object to manage the
> >> disposal if they use the disposal functionality properly and you to
> >> handle the "just in case" if they don't.
> >>
> >> That said you probably should consider making sure that you close your
> >> connection as soon as you are done using it (rather than relying on
> >> object destruction) so you don't accidentally bleed connections by
> >> hoping your finalizer will someday be called when the garbage collector
> >> gets around to it.  If designed properly you won't usually see enough
of
> >> performance hit from doing this as you might think and it keeps
> >> everything as clean and available as possible.  Hope that helps.
> >>
> >> Have A Better One!
> >>
> >> John M Deal, MCP
> >> Necessity Software
> >>
> >> Ken Varn wrote:
> >> > I read in the MSDN docs that you should not call any Close() method
from
> >a
> >> > connection object or data reader object from within a finalizer.  I
> >don't
> >> > quite understand why.  Could someone explain?
> >> >
> >
> >
> >
>
>
> -- 
>
> This posting is provided "AS IS" with no warranties, and confers no
rights. Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> Note:  For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.
>

Relevant Pages

  • Re: " //Clean Up managed resources " f&*ck
    ... time (such as releasing internal unmanaged resources). ... Since Dispose ... methods is responsible for cleaning resources, the finalizer code ... it is about 'managed resource'. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Clean Up managed resources
    ... these have unmanaged resources. ... If somebody called Dispose on your object, ... If the finalizer is called on your object, ... threads while it determines reachability from all the different roots. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Disposing of brushes
    ... fonts etc take GDI handles - and you could run short of those ... unmanaged resources, the number one reason to have IDisposable? ... in this special case the finalizer will call Disposefor you, ... Dispose() in the finalizer and supress the finalizer if Dispose is ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: StatusStrip control leaks its collection items
    ... That's what the garbage collector is for. ... Dispose() on the object when you're done with it. ... WHEN the unmanaged resources get released, or if you need to force ... The finalizer will eventually take care of it as long as ...
    (microsoft.public.dotnet.framework)
  • Re: How to clear controls from a form - Help Needed
    ... some other links I got the impresion that including a dispose method in your ... class modules actually was not needed unless you had some unmanaged resources ... An object that implements Dispose often also implements a Finalizer. ... Finalizer is code that runs when the garbage collector frees the ...
    (microsoft.public.dotnet.languages.vb)