Dispose Again!

[Cor Ligthert]

This means. that what you write should be done, this is about class that

derives from this list and those classes themselves.

This means that what you write should be done for all classes that by
instance derive from components.

This..........................

 

[Cor Ligthert]

Scott,

Maybe it is good to remind that I wrote this in my starting answer.

Therefore I inherit from components when I make a class from which I have
slightly the idea that it has unmanaged resources in it.

This means for me every class which has interop or an Api in it.

(In fact I just open a component in the items and use that template).

Cor

 

[JD]

Calling a dispose individualy explicitly (in classes where Idispose is

implemented) optimezes the process of garbage collection. However the GC is
running in the idle time of a program. For me it is foolish to use the
running proces time from a program to optimize processes which run in idle
time like the GC.

The GC does not run in idle time. It runs when there is a need to collect
memory. If a program is doing nothing or is idle the GC will not run and
will not collect any objects. The GC runs more when the progam is actually
busy!

 

[JD]

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) "Appropriately" 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...

I agree with these three suggestions. I myself use 3, but when I see people
struggling with Dispose I suggest 2. I strongly agree about number 1.

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
I'm sincerely sorry about the off color joke. It was meant purely as a joke,
and nothing about your culture.


However my question about what you are talking about in this thread still
stands!

There are times when what you state makes no sense (such as your answers in
this thread). There are times when your answers make a lot of sense!

I'm certain it is not just me, as I've noticed others have questioned a
number of your answers also!

You have lost all your credits from me.

Unfortunately I cannot say the same about you! As you do provide valuable
information in the newsgroups. Its just sometimes (such as this thread) it
is hard to make heads or tails out of what you are saying. When I or others
ask for clarification of what you were thinking, you sometimes get overly
defensive or a little less coherent (such as posting the list of classes).

Just a thought
Jay

 

[Michael C#]

Is it possible, that in the future, the Dispose() method on some Framework
objects might include more clean-up in their Dispose() method than they do
now? For instance, Angel Saenz-Badillos from MS posted a message to Cor
previously in the ADO.NET newsgroup:
http://groups-beta.google.com/group...ion+pooling"+sahil+malik#doc_01e5f2f511b2f7bd

He basically says that they were going to put more functionality in the
SqlCommand Dispose() method which would have made it necessary to call
Dispose() on your SqlCommand's in .NET 2.0. They ended up leaving it out,
but the fact they toyed with the idea leads me to believe there might be
changes down the road.

With that in mind, if they *had* implemented this particular change, or
changes in other class's Dispose() methods, does that mean all those who
pick and choose when and where to call Dispose() might spend fair amounts of
time re-learning a new set of rules and changing their programming patterns?
I still think #2 is the best fit for my needs. After all, if they change
the actual functionality of the Dispose() method for a particular class I
use in the future, I won't end up wasting a bunch of time trying to "fix"
all my code to match the newest Developer Recommendations.

Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.

 

[Michael C#]

Yeah Cor, I just visited that new link and I still don't see how it relates?

 

[Scott M.]

Yes, but then you went on to say:

"There is no need to dispose any object of system.data."

And that is what I responded to because that is untrue.

 

[Scott M.]

Dispose is nothing more than a method that the class creator adds when they
need a place to write code that will release the unmanaged resources that
the class uses. It is up to the class user to call this method.

That's it...that's what dispose is.

 

[Michael C#]

Dispose is nothing more than a method that the class creator adds when
they need a place to write code that will release the unmanaged resources
that the class uses. It is up to the class user to call this method.

That's it...that's what dispose is.

That's great. Nice quick, easy definition. I'm sure it sheds new light on
the problem of when to call Dispose() and when to ignore it completely.

I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".

 

[Scott M.]

I think the one thing we can all agree upon is that nothing is "automatic".
It comes down to this for me:

1. I know that the class needs it's dispose method to be called and I call
it (OleDbConnection, for example).
2. I know the class has a dispose, but it is a "relic" of inheritance and
doesn't need to be called, so I don't call it (label, for example).
3. There is no dispose method, so problem solved.
4. I'm not sure so:
4a. I call it anyway to be safe.
4b. I research the class to see if it is indeed needed or is a relic.

 

[Scott M.]

No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use unmanaged
resources and SHOULD be disposed. I'm not talking about labels here. You
said there is no reason to call dispose on any of the data classes. I must
disagree. I believe that to be incorrect.

 

[Jay B. Harlow [MVP - Outlook]]

Michael,

With that in mind, if they *had* implemented this particular change, or
changes in other class's Dispose() methods, does that mean all those who
pick and choose when and where to call Dispose() might spend fair amounts
of time re-learning a new set of rules

IMHO the "set of rules" remains constant, by "set of rules" I mean JD's
three rules which are rather simple. IMHO my list of 3 are more mantalities
for managing JD's three rules...

What would change is the list classes that now either "require" or not
"require" dispose changes. I would expect classes that went from not
requiring Dispose to now requiring Dispose to directly or indirectly to show
up under the "Profiling & various exceptions" clause of my 3 rules...

Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.

As I've stated before, VB.NET 2005 will get the same "using" statement that
C# has to help manage IDisposable classes...

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Michael,

I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".

The GC will never directly call Dispose! The GC will only directly call
Finalize! Finalize may or may not call Dispose. Normally Dispose & Finalize
will call a common routine.

http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconFinalizeDispose.asp

Hope this helps
Jay

 

[David]

Michael and Dennis,

As JD has suggested Dispose can do one of three things:

1) nothing
2) cleans up unmanaged resources
3) cleans up managed resources

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.

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) "Appropriately" 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...

#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.

 

[David]

No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use unmanaged
resources and SHOULD be disposed. I'm not talking about labels here. You
said there is no reason to call dispose on any of the data classes. I must
disagree. I believe that to be incorrect.

This depends a bit on the type of data resources you're using. The
SqlClient stuff never needs to be disposed. OleDb objects, on the other
hand, can use a tiny bit of COM memory and so possibly they should be
Disposed (in practice I'm not so sure it matters).

Of course, there's an awful lot of other data libraries out there and it
would be hard to generalize about them.

 

[Cor Ligthert]

Michael

Yeah Cor, I just visited that new link and I still don't see how it
relates?

This was an answer on Jay, where he told that some classes in this list did
not derive from component.

It gives as well an answer on the question that from every method which have
a dispose the dispose should be used. All those methods and which derive
from those have a dispose just because it is in the top base class.

Cor

 

[Cor Ligthert]

Scott,

"There is no need to dispose any object of system.data."

And that is what I responded to because that is untrue.

No that did I not say, because I showed you the message about connection and
any dispose method can be overridden. However, for the rest I would not know
any object in system.data that in my opinion *should* be disposed.

About the system.data object has dispose often been in the newsgroup Adonet.
I know that Angel has advised to dispose every object. However when I asked
him once why, he told more or less that it was his personal way of doing
things.

However will never tell here in a newsgroup not to dispose, I tell to use it
when it has sense, however not the sentence "When there is a dipose method
it should be used".

And that is what this thread in this message as answer on Dennis started
with.

I have implemented the practice of "If it's got a dispose method, then
call it when I'm thru with it and if it doesn't have a dispose method,
don't worry about it!"

Cor

 

[Cor Ligthert]

Jay,

I'm sincerely sorry about the off color joke. It was meant purely as a
joke, and nothing about your culture.

Ok accepted.

However my question about what you are talking about in this thread still
stands!

I have taken some time about the dispose, because it is something where
about in my opinion is very poorly about written and gets a different
setting when you read about it in time from old documents to newer
documents.

The old are in the style, "do dispose because it can not hurt" while the
newer get more another trend however still in my opinion not well described.
You can see that in my opinion in that "Improving .NET Application
Performance and Scalability" link you once showed me. There is a lot very
good written, however the dispose has again that "it can not hurt" trend for
me and is very brief written

Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.
As they all contain classes that deal with "external" (aka unmanaged)
resource.

The big point for me is, that an unmanaged resource are in all documents
indirectly and flaw connected with managed code. Managed code is to manage
resources. There is not written something real about unmanaged resources in
that relation. For me is as long that I don't have a good document what is
an *unmanaged resource* (not a blog or whatever especially not from a
classic VB MVP) an unmanaged resource something that comes from an API,
wherefore than Idisposable should be implemented.

We arguing in this thread part of the text bellow from Dennis, where I told
to him that what he wrote was not the right method. As reaction on that you
tell in this thread part, that I don't know what I am talking about.

I have implemented the practice of "If it's got a dispose method, then call
it when I'm thru with it and if it doesn't have a dispose method, don't
worry about it!"

Therefore tell to me than what is wrong or smoked or whatever when I tell
that this is not the right but even oposite from that. I have told that when
you build your own class and it has unmanaged resource you would have to
implement Idisposable (not in those words because I gave the advice to use
components as base class where that is implemented).

There are times when what you state makes no sense (such as your answers
in this thread). There are times when your answers make a lot of sense!

I have told you more that when you *think* that when my answers as above
don't make sense to ask. However you have than in my expirience the attitude
to write than directly as if other people don't understand it. I told you
more times, that I read documentation, however when I don't trust it,
investigate it as far as I can go. Often when I wrote text like this you
give an answer starting with (shakes
head)...............................................

I'm certain it is not just me, as I've noticed others have questioned a
number of your answers also!

I am glad when people ask than. Than I try to clarify it, and when they
*proof* that I am wrong I have learned something again and thank them.

A sample from such a discussion where it was the oposite.
http://groups-beta.google.com/group/microsoft.public.dotnet.languages.vb/msg/c2d944d25a937c26

Unfortunately I cannot say the same about you! As you do provide valuable
information in the newsgroups. Its just sometimes (such as this thread) it
is hard to make heads or tails out of what you are saying. When I or
others ask for clarification of what you were thinking, you sometimes get
overly defensive or a little less coherent (such as posting the list of
classes).

A problem can be that I don't like the inline answers because they go
everytime further and further away from the starting subject. I try to keep
me on the subjects as they are top down in a thread. For some is that hard
to read. When you want that, will I change that style for you as well as I
did it for Herfried.

And maybe by coincidence however because that you wrote now "Just a
thought", when you write "I hope this helps" or just denies my answers
without any proof or reference in it, or whithout the text "in my opinion" I
probably become in a kind of what you call "overly defensive or a little
less coherent". There are only two persons who can bring me in this state in
these newsgroups. (The other one is not from this newsgroup and is now
mostly ignored by me)

As last about the list of classes. I expect that when you have written that
something is "false" and I show a list wherin that is in my opinon "true"
you understand what I mean.

I hope this clarifice something.

Cor

 

[Cor Ligthert]

Scott,

No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use
unmanaged resources and SHOULD be disposed. I'm not talking about labels
here. You said there is no reason to call dispose on any of the data
classes. I must disagree. I believe that to be incorrect.

I have never stated that the Connection not *should* be disposed for at
least a year now. So I cannot believe that you wrote is true. In opposite of
that, I am always the one who advices in these newsgroups to use that
instead of the close for the connection.

My problem in this with the dispose is, that there is always written about
unmanaged resources. However until now I never found a good link on MSDN
what they mean with an "unmanaged resource", except some blogs from by
instance old VB classic MVP's, which are often in conflict inside the text.

Cor