Prev: Trouble With Timer
Next: Reading filenames into listbox
From: Gale Green on 4 Apr 2010 12:48

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.
From: Tom Shelton on 4 Apr 2010 13:20
On 2010-04-04, Gale Green <gale(a)databeat.fsnet.co.uk> wrote:
>
> 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.

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

--
Tom Shelton
From: Gale Green on 4 Apr 2010 13:34
On Sun, 04 Apr 2010 10:20:33 -0700, Tom Shelton
<tom_shelton(a)comcastXXXXXXX.net> wrote:

> Good stuff.

Thanks for all that Tom. All is now clear, and I agree with your
attitude to the Dispose method.

Gale.
From: Cor Ligthert[MVP] on 5 Apr 2010 02:13
However, in fact Tom does not call the Dispose method in 90% of the cases,
because he knows that those are implicitly called.


"Gale Green" <gale(a)databeat.fsnet.co.uk> wrote in message
news:k8jhr5lsh37g7bu21era172b2i6ijera5p(a)4ax.com...
> On Sun, 04 Apr 2010 10:20:33 -0700, Tom Shelton
> <tom_shelton(a)comcastXXXXXXX.net> wrote:
>
>> Good stuff.
>
> Thanks for all that Tom. All is now clear, and I agree with your
> attitude to the Dispose method.
>
> Gale.

From: Tom Shelton on 5 Apr 2010 04:53
On 2010-04-05, Cor Ligthert[MVP] <Notmyfirstname(a)planet.nl> wrote:
> However, in fact Tom does not call the Dispose method in 90% of the cases,
> because he knows that those are implicitly called.
>
>

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?

--
Tom Shelton
 |  Next  |  Last
Pages: 1 2 3
Prev: Trouble With Timer
Next: Reading filenames into listbox