Object disposal guidance needed

  • Thread starter Thread starter Gale Green
  • Start date Start date
G

Gale Green

Hi all.

I'm a recent migrant from VB6 so I'm used to creating references to
objects and then setting them to Nothing when they are no longer
needed.

Do I understand correctly that setting to Nothing is unnecessary in VB
2008 when the owning class or form is about to close anyway?

Can disposal of objects always be left to the garbage collector, or
are there times when setting to Nothing would be useful or desirable?

Second, though related, question: when showing a form, using
..ShowDialog, I always call the form's .Dispose method on return.
Should I set the form to Nothing as well? Everything seems to work
whether I set to Nothing or not, but I can't tell whether resources
are being retained unnecessarily.

Thanks for any guidance.

Gale.
 
Hi all.

I'm a recent migrant from VB6 so I'm used to creating references to
objects and then setting them to Nothing when they are no longer
needed.

Do I understand correctly that setting to Nothing is unnecessary in VB
2008 when the owning class or form is about to close anyway?

Can disposal of objects always be left to the garbage collector, or
are there times when setting to Nothing would be useful or desirable?

Second, though related, question: when showing a form, using
.ShowDialog, I always call the form's .Dispose method on return.
Should I set the form to Nothing as well? Everything seems to work
whether I set to Nothing or not, but I can't tell whether resources
are being retained unnecessarily.

Thanks for any guidance.

Gale.
Click to expand...

Setting an local object to nothing is almost always useless - just as it was
in VB6 (except in very rare circumstances). About the only time setting an
object to nothing is valuable is when it is a module or class level reference.

The only time special handling is required is when an object implements the
IDisposable interface. This is generally an indication that the object holds
some resource (most often unmanaged) that needs cleanup. In those cases you
will generally want to make sure that Dispose is called on the object when you
are through with it. The easiest way to do this is to use Using...

Using d As New MyDialog()
If d.ShowDialog() = DialogResult.OK Then
' do cool stuff
End If
End Using

The value of using is that it will ensure that Dispose is called on the
object, even if an exception is thrown. It is bascially syntactic sugar for a
Try/Finally block.

There are objects that implement IDisposable that calling Dispose is not
strictly necessary - such as DataSet. These objects actually end up with
Dispose because they inherit from component. You may see advice from some
that says to avoid calling dispose on these objects. I personally disagree
with this advice for a number of reasons and suggest that you make it a strict
rule to always call dispose if an object implments IDisposable.

The reasons I disagree is because:

1) It makes the rules for Dispose more complicated - always call dispose
except on object a, b, c, d. It's easier to remember, if an object implements
IDisposable call dispose.

2) In OOP it is generally a bad idea to program to an objects implementation.
As a rule, it is better to program to an Interface - and ignoring dispose on
certain objects means you are programming against a known implementation
details. This can leave your code broken if a future implementation
changes...

But, feel free to follow what ever rule you are most comfortable with...
 
However, in fact Tom does not call the Dispose method in 90% of the cases,
because he knows that those are implicitly called.
 
However, in fact Tom does not call the Dispose method in 90% of the cases,
because he knows that those are implicitly called.
Click to expand...

Cor... It is true that I do not often call the Dispose method directly -
I generally enclose disposable objects in a using block, which guarentees the
call to dispose. The point that I was makeing is that I generally code to
make sure that the object is disposed when I am done with it. I in fact,
pointed this out in my post to the OP - the use of using. I am suggesting
that the OP does likewise. Making sure a dispose call is made, implicitly via
using, or explicitly amounts to about the same thing in my book.

I wonder, did you have some valid point to make?
 
Yes I've a point, don't tell Wabash, it seems just to create a Trolling
thread, this is not the VB6 newsgroup.

You wrote
There are objects that implement IDisposable that calling Dispose is not
strictly necessary - such as DataSet. These objects actually end up with
Dispose because they inherit from component. You may see advice from some
that says to avoid calling dispose on these objects. I personally
disagree
with this advice for a number of reasons and suggest that you make it a
strict
rule to always call dispose if an object implments IDisposable.
Click to expand...

What you wrote, is the same reason why the OP was setting anything to
Nothing in VB6, somebody had written that and he took the chance that that
one was right as the best. Now you tell him that he should change that
practice to use on everything which implements Idisposable the "often"
senseless dispose method, which only trashes often code in the same way as
for ever using nothing in VB6.

Form Closing
label1.dispose
Label2.dispose
Label3.dispose

Why don't you write that he should always count like this.

Result = Cint(X.ToString) += 1 because every value type implements even an
overloaded ToString method, so in your theory it must be used.

All Forms controls and components implement the dispose method inherited
from the Component class.

You know likewise me that where calling the dispose is needed, this for
forms and components is done implicit but since version 2005 hidden for most
beginners in VB.Net in the designer part.

You know also very well, that I am almost the only one who shows in the
Microsoft Visual Basic forums samples with "using", so don't accuse me from
things, which you know that aint true.

You know how some regulars in this newsgroup disagree about this with you,
while other of those agree, no problem but don't see it as a kind of
evangelism to newbie's, who have set in past everything to nothing, just to
take no risk and somebody wrote it.

With every object which implements IDisposable, can be used with Using, so
calling Dispose has no sense anymore, use the better code for that, it
trashes at least not the code like I showed above.

So where Dispose is needed it is better to use the Using keyword and if you
don't know, you can also use that using keyword.

Luckily the newer Classes don't implement IDisposale anymore so much anymore
as in past.

Your message could have also been without that sentence I quoted, it would
have been a good and correct message.

Now it seems at least to me more a little bit to kick some regulars here to
the head.

Cor
 
Hmmm ,,,.........

to the OP

This is discussed here manny times and it mostly indeed ends in a nothing
saying thread

http://www.developersdex.com/vb/message.asp?p=1121&r=6705983
http://bytes.com/topic/visual-basic-net/answers/444984-command-close-vs-command-dispose
http://www.pcreview.co.uk/forums/thread-3854824-3.php
etc etc etc etc etc etc

http://www.google.nl/#hl=nl&source=...=f&aqi=&aql=&oq=&gs_rfai=&fp=6bc54ad77a0995ae

Read a few of them and try some of the examples i showed in these threads
and you will notice that your program in some of my described situations can
run forever
while if you follow the Not call dispose camp in the same situation your
progs will crash or degrade overall system performance .

In case you are wondering ,, yes i am in the call dispose and set to nothing
camp when it actually makes sense to do so , and if you are in doubt just do
it, as it also doesn`t hurt while omitting it wil sure hurt your app.

As i am a so called "Balena" programmer i follow his design patterns ( wich
actually conform to MS standards as he is also the writer of the MS VB core
reference guides ) described in the Core reference guides of Visual Basic
..Net and in these guide there are examples where a object pointer is set
to nothing and it perfectly makes sence to do so , i have posted this
example several times in the group so with the provided links you should
find it :-) .

Regards

Michel Posseth
 
Yes I've a point, don't tell Wabash, it seems just to create a Trolling
thread, this is not the VB6 newsgroup.

You wrote

What you wrote, is the same reason why the OP was setting anything to
Nothing in VB6, somebody had written that and he took the chance that that
one was right as the best. Now you tell him that he should change that
practice to use on everything which implements Idisposable the "often"
senseless dispose method, which only trashes often code in the same way as
for ever using nothing in VB6.
Click to expand...

And as always, we disagree on this point (and despite your inferences, you are
almost the only one I know who does). I see you once again bring in a
long set of unrelated arguments. I will ignore the rest of your post, and
just try to make sure my position is clear.

Integer.ToString(): Totally irelavent. I am in no way saying that every
method of an object must be called simply because it exits.

IDisposable is part of a resource management pattern. The presence of
IDisposable is supposed to signal to the developer using the object that this
class potentially contains resources that should be released as early as
possible. As such, it should be called when you are done with the object.

Now, I treat controls and components that are sited on forms a bit
differently, because the system generates the code to dispose of these. In
other words, the parent forms dispose method disposes all of it's children.
So, using a dialog:

Using dlg As New MyDlg
If dlg.ShowDialog() = DialogResult.OK Then
...
End If
End Using

Is sufficent to dispose the form and all of it's children. So, with the
exception of the main form - since that object lives the entire life of the
program, it's a pretty safe bet that I am making sure a call to dispose is
made.

Other objects, that maybe used as local values, ect that implement Dispose are
almost always wrapped in a using block - so I very rarely call Dispose
directly. And yes, I do advocate the use of a using with classes such as
dataset, memorystream, etc. The main reason is that I like to keep rules
simple and consistant. And, I don't believe in programming to an object's
implementation. Just because I've looked, and I know a memorystream holds no
unmanaged resources - it's simply wrapper for a byte array, I still wrap it in
a using block. Why? Because I try to program to interfaces and not
implementations. It implements IDisposable, that is an interface with a
special meaning - so I follow the contract.
 
And as always, we disagree on this point (and despite your inferences, you
are
almost the only one I know who does). I see you once again bring in a
long set of unrelated arguments. I will ignore the rest of your post, and
just try to make sure my position is clear.
Click to expand...
There is a guy here already a while active with the name Armin Zingler,

It is of course possible you've never seen any post from him.

He has in this no other opinion than me.

Another guy, Herfried Wagner. Ever seen a post from him?
The same.

In past; somebody who changed his opinion and then told the same like me,
Jay B. Harlow.

A pity that you've never seen any post from them about dispose.

If you had read my last post in this thread, you would have seen, that I am
not discussing the use of using.
I assume that I am making more propaganda (at least in quantity) for that
then you.
However, in my idea is therefore the use of the dispose method a proof of
non well formed code.

Cor
 
Am 05.04.2010 19:18, schrieb Cor Ligthert[MVP]:
There is a guy here already a while active with the name Armin Zingler,
Click to expand...

I'm not really getting your point mentioning my name, but I was about to
reply to Tom's message and say that I 100% agree with him.

Despite, let's stay friends. ;)
 
The last one or the first one in which he writes that dispose should always
be used?

The last one is completely different from the first one, and I am writing
about his first one, where he tells he is a follower from those who write.

They did not put for nothing the Idisposable interface on those classes. It
is a contract so it should be used.

I was not aware it was your opinion, but glad to know. Maybe you wont
believe, but then I don't agree that with you.

:-)

Cor
 
Am 05.04.2010 20:36, schrieb Cor Ligthert[MVP]:
The last one or the first one in which he writes that dispose should always
be used?

The last one is completely different from the first one, and I am writing
about his first one, where he tells he is a follower from those who write.
Click to expand...

I read them again but I don't see a contradiction.
They did not put for nothing the Idisposable interface on those classes. It
is a contract so it should be used.
Click to expand...

yes, should be used.
I was not aware it was your opinion, but glad to know. Maybe you wont
believe, but then I don't agree that with you.

:-)
Click to expand...


Maybe it's all a big misunderstanding?!
 
On Mon, 5 Apr 2010 13:15:11 +0200, "Michel Posseth [MCP]"

Thanks for all that, I shall have a read. I thought it was a fairly
straightforward question - I never expected to start a thread going.
Oh well.

I shall have to get the Balena book - I used his VB book when I first
started using VB6.

Thanks again.

Gale.
Hmmm ,,,.........

to the OP

This is discussed here manny times and it mostly indeed ends in a nothing
saying thread

http://www.developersdex.com/vb/message.asp?p=1121&r=6705983
http://bytes.com/topic/visual-basic-net/answers/444984-command-close-vs-command-dispose
http://www.pcreview.co.uk/forums/thread-3854824-3.php
etc etc etc etc etc etc

http://www.google.nl/#hl=nl&source=...=f&aqi=&aql=&oq=&gs_rfai=&fp=6bc54ad77a0995ae

Read a few of them and try some of the examples i showed in these threads
and you will notice that your program in some of my described situations can
run forever
while if you follow the Not call dispose camp in the same situation your
progs will crash or degrade overall system performance .

In case you are wondering ,, yes i am in the call dispose and set to nothing
camp when it actually makes sense to do so , and if you are in doubt just do
it, as it also doesn`t hurt while omitting it wil sure hurt your app.

As i am a so called "Balena" programmer i follow his design patterns ( wich
actually conform to MS standards as he is also the writer of the MS VB core
reference guides ) described in the Core reference guides of Visual Basic
.Net and in these guide there are examples where a object pointer is set
to nothing and it perfectly makes sence to do so , i have posted this
example several times in the group so with the provided links you should
find it :-) .

Regards

Michel Posseth
Click to expand...
 
Back
Top