Re: Dispose Again!
On 2005-03-20, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com> wrote:[color=blue]
> Michael and Dennis,[color=green]
>> So again, we get back to someone's recommendations somewhere; presumably
>> the class developer's recommendation.[/color]
>
> As JD has suggested Dispose can do one of three things:
>
> 1) nothing
> 2) cleans up unmanaged resources
> 3) cleans up managed resources[/color]
True, but I think this hides what is really the cause of most of the
confusion around Dispose, which is that Dispose can do different things
at different times.
Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime. It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else). But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
[color=blue]
> Now IMHO there are 3 schools of thought on calling Dispose:
>
> 1) Never call Dispose, instead let the Finalizer take care of unmanaged
> resources. This is probably the worst & sloppiest attitude you can take on
> calling Dispose. Profiling & various exceptions will indicate problems when
> using this method.
>
> 2) Always call Dispose, the "better safe then sorry" pattern.
>
> 3) "Appropriat ely" call Dispose. Unfortunately this is the hardest one to
> achieve, as you need to learn from experience, others, or profiling &
> various exceptions... It is the one I strife for...[/color]
#3 is what most of us probably do, and it's the best solution for a bad
problem IMHO.
But in the land of inheritance and interfaces, there's the possibility
here of a time bomb. I may know I don't have to Dispose a
SqlDataAdapter or DataSet, but what if my DAL hands me an IDataAdapter
from some weird implementation that needs disposing and or a DataSet
object that *might be* a class that inherits DataSet, and needs to
de-allocate precious resources in Dispose? Experience and profiling
doesn't help here, since the type of object I'm receiving might change
long after development has finished.
I choose to pretty much ignore those issues right now. But tossing
IDisposable on a ton of objects that don't actually need runtime
disposing was a pretty bad idea on the part of MS.
On 2005-03-20, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com> wrote:[color=blue]
> Michael and Dennis,[color=green]
>> So again, we get back to someone's recommendations somewhere; presumably
>> the class developer's recommendation.[/color]
>
> As JD has suggested Dispose can do one of three things:
>
> 1) nothing
> 2) cleans up unmanaged resources
> 3) cleans up managed resources[/color]
True, but I think this hides what is really the cause of most of the
confusion around Dispose, which is that Dispose can do different things
at different times.
Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime. It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else). But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
[color=blue]
> Now IMHO there are 3 schools of thought on calling Dispose:
>
> 1) Never call Dispose, instead let the Finalizer take care of unmanaged
> resources. This is probably the worst & sloppiest attitude you can take on
> calling Dispose. Profiling & various exceptions will indicate problems when
> using this method.
>
> 2) Always call Dispose, the "better safe then sorry" pattern.
>
> 3) "Appropriat ely" call Dispose. Unfortunately this is the hardest one to
> achieve, as you need to learn from experience, others, or profiling &
> various exceptions... It is the one I strife for...[/color]
#3 is what most of us probably do, and it's the best solution for a bad
problem IMHO.
But in the land of inheritance and interfaces, there's the possibility
here of a time bomb. I may know I don't have to Dispose a
SqlDataAdapter or DataSet, but what if my DAL hands me an IDataAdapter
from some weird implementation that needs disposing and or a DataSet
object that *might be* a class that inherits DataSet, and needs to
de-allocate precious resources in Dispose? Experience and profiling
doesn't help here, since the type of object I'm receiving might change
long after development has finished.
I choose to pretty much ignore those issues right now. But tossing
IDisposable on a ton of objects that don't actually need runtime
disposing was a pretty bad idea on the part of MS.
Comment