Best Practice - Destroying objects

[=?Utf-8?B?VGltIE1hcnNkZW4=?=]

Hi,
I am after suggestions on the best practice declaring and destroying objects.

some example code:

Private Sub MySub

Dim frmMyForm As MyForm

Try

frmMyForm = New MyForm
frmMyForm.DoSom ething

Catch ex As Exception
ProcessError(ex )
Finally
If Not frmMyForm Is Nothing Then
frmMyForm.Dispo se()
frmMyForm = Nothing
End If
End Try
End Sub

I declare my object (form in this case) at the beginning of the routine.
I create it and us it.
Then I destroy it in the Finally section.

I use a Try Catch to capture and process any errors resulting from the use
of the form (or object).
I destroy the objects in the Finally section so that the code is run even if
there is an error. If it was in the main Try section it may not be run.

However if the logic is used in VB2008 I get a warning saying I am using a
variable before it is assigned a value.

How do I ensure I cater for unexpected errors?
How do I declare my objects?
Do I destroy them or simple let GC do it.?
Your opinions please







--
Tim

[rowe_newsgroups]

Re: Best Practice - Destroying objects

On Sep 12, 8:40 am, Tim Marsden <tm...@newsgrou p.nospamwrote:

Hi,
I am after suggestions on the best practice declaring and destroying objects.
>
some example code:
>
Private Sub MySub
>
    Dim frmMyForm As MyForm  
>
    Try
>
       frmMyForm = New MyForm  
       frmMyForm.DoSom ething
>
     Catch ex As Exception
       ProcessError(ex )
     Finally
       If Not frmMyForm Is Nothing Then
          frmMyForm.Dispo se()
          frmMyForm = Nothing
       End If
    End Try
End Sub
>
I declare my object (form in this case) at the beginning of the routine.
I create it and us it.
Then I destroy it in the Finally section.
>
I use a Try Catch to capture and process any errors resulting from the use
of the form (or object).
I destroy the objects in the Finally section so that the code is run evenif
there is an error. If it was in the main Try section it may not be run.
>
However if the logic is used in VB2008 I get a warning saying I am using a
variable before it is assigned a value.
>
How do I ensure I cater for unexpected errors?
How do I declare my objects?
Do I destroy them or simple let GC do it.?
Your opinions please
>
--
Tim  

For IDisposable objects, I recommend you dispose them whenever you
can. This topic is one of huge debate (Cor will be here shortly saying
the opposite of what I am) so I won't get into the why, but I'll
encourage you to search the archives for the discussions.

In your example, either of the below should work (I prefer the latter)

//////////////
Dim frmMyForm As MyForm = Nothing
Try
frmMyForm = New MyForm
frmMyForm.DoSom ething
Catch ex As Exception
ProcessError(ex )
Finally
If Not frmMyForm Is Nothing Then
frmMyForm.Dispo se()
frmMyForm = Nothing
End If
End Try
//////////////

//////////////
Try
Using frmMyForm As New MyForm()
frmMyForm.DoSom ething()
End Using
Catch ex As Exception
ProcessError(ex )
End Try
//////////////

Thanks,

Seth Rowe [MVP]

http://sethrowe.blogspot.com/

[Brian Gideon]

Re: Best Practice - Destroying objects

On Sep 12, 7:40 am, Tim Marsden <tm...@newsgrou p.nospamwrote:

Hi,
I am after suggestions on the best practice declaring and destroying objects.
>
some example code:
>
Private Sub MySub
>
    Dim frmMyForm As MyForm  
>
    Try
>
       frmMyForm = New MyForm  
       frmMyForm.DoSom ething
>
     Catch ex As Exception
       ProcessError(ex )
     Finally
       If Not frmMyForm Is Nothing Then
          frmMyForm.Dispo se()
          frmMyForm = Nothing
       End If
    End Try
End Sub

Setting frmMyForm = Nothing is pointless here since the variable has
local scope. In fact, the object referenced by frmMyForm is eligible
for collection before that line even executes. Of course, that is
assuming the CLR even executes it in first place since it may be
optimized out.

>
I declare my object (form in this case) at the beginning of the routine.
I create it and us it.
Then I destroy it in the Finally section.
>
I use a Try Catch to capture and process any errors resulting from the use
of the form (or object).
I destroy the objects in the Finally section so that the code is run evenif
there is an error. If it was in the main Try section it may not be run.
>
However if the logic is used in VB2008 I get a warning saying I am using a
variable before it is assigned a value.

Hmm...I'll have to double check the rules for definite assignment, but
I suspect the compiler is recognizing that the instantiation of MyForm
could throw an exception resulting in a usage of the variable in the
finally section before it is definitely assigned.

>
How do I ensure I cater for unexpected errors?

Use the 'using' construct.

How do I declare my objects?

Dim frmMyForm As MyForm = Nothing would have worked.

Do I destroy them or simple let GC do it.?

If an object implements IDisposable then it is recommened that you
always call Dispose.

Your opinions please
>
--
Tim  

[Cor Ligthert[MVP]]

Re: Best Practice - Destroying objects

Tim

Finaly, is only a part of a try catch block, where finaly means that it
always is done as long as the computer is not unplugged.

Setting the reference of an object to nothing is absolute without any sense
in VB after VB6, simple because it does nothing more then an instruction to
set a memory address to all zeroes. The object still stays at the managed
heap until it is removed by the Garbage Collector.

You are nowhere destroying any object in your code. You use dispose which as
Idispose is right implemtend releases all unmanaged resource used in your
object (as those are there). Dispose is a methode from components, while 20%
of the classes (especially controls) inherits that.

However, by instance in SharePoint and more classes, where the managed code
is only a wrapper around Com objects, it is adviced to use dispose to
release those unmanaged resources. If you are using SharePoint, then simple
invoke the dispose method to let the Idisposable section do its work.
Therefore it is by the SharePoint team called good practise to invoke
dispose at the end of every object (They have changed that text lately, it
is now more or less, good practise for Sharepoint objects).

Be aware that from the first day of managed code the dispose was seen as a
replacement for the deconstructor. In those days (and in non managed C++ but
not in Java) you should have used that deconstructor, therefore is in Java
and other managed languages like VB now the Garbage Collector. (And that is
in fact why it is called managed code). Some people started paroting, that
it was good practise to use Dispose as the method was in a class, the same
as it is with non managed code good practise to descruct every object. There
are tons of pages on Internet where people are only telling that it is good
practise, but never tell why (or something as it does not harm).

To destroy an object is possible by using the deconstructor. However, it is
strongly adviced not to do that and let the Garbage Collector do its work.

Have a look at the designer code of a form (it is in more wizards), there
you see the implementation of the IDispose which is done at every close of a
form. If you create yourform yourself, then you have to implement this code
as well yourself to have benefit from the dispose. If you use objects which
implements very much handles like pens, then it is aviced to use then
dispose (to release the handles) everytime before there the object is
nowhere referenced anymore (and that is not only its own reference, that one
does as I started with, in this case nothing).

Cor



"Tim Marsden" <tmqsl@newsgrou p.nospamschreef in bericht
news:B243FC1A-04B2-4DA5-9252-7F4CCB6ECD91@mi crosoft.com...

Hi,
I am after suggestions on the best practice declaring and destroying
objects.
>
some example code:
>
Private Sub MySub
>
Dim frmMyForm As MyForm
>
Try
>
frmMyForm = New MyForm
frmMyForm.DoSom ething
>
Catch ex As Exception
ProcessError(ex )
Finally
If Not frmMyForm Is Nothing Then
frmMyForm.Dispo se()
frmMyForm = Nothing
End If
End Try
End Sub
>
I declare my object (form in this case) at the beginning of the routine.
I create it and us it.
Then I destroy it in the Finally section.
>
I use a Try Catch to capture and process any errors resulting from the use
of the form (or object).
I destroy the objects in the Finally section so that the code is run even
if
there is an error. If it was in the main Try section it may not be run.
>
However if the logic is used in VB2008 I get a warning saying I am using a
variable before it is assigned a value.
>
How do I ensure I cater for unexpected errors?
How do I declare my objects?
Do I destroy them or simple let GC do it.?
Your opinions please
>
>
>
>
>
>
>
--
Tim

[Cor Ligthert[MVP]]

Re: Best Practice - Destroying objects

Seth,

Is it possible to stop calling my name everytime in messages especialy as
you disagree with me?

Thanks,

Cor


"rowe_newsgroup s" <rowe_email@yah oo.comschreef in bericht
news:1f31e3b1-cddc-4d4c-99a5-b92ac8b9383a@d4 5g2000hsc.googl egroups.com...
On Sep 12, 8:40 am, Tim Marsden <tm...@newsgrou p.nospamwrote:

Hi,
I am after suggestions on the best practice declaring and destroying
objects.
>
some example code:
>
Private Sub MySub
>
Dim frmMyForm As MyForm
>
Try
>
frmMyForm = New MyForm
frmMyForm.DoSom ething
>
Catch ex As Exception
ProcessError(ex )
Finally
If Not frmMyForm Is Nothing Then
frmMyForm.Dispo se()
frmMyForm = Nothing
End If
End Try
End Sub
>
I declare my object (form in this case) at the beginning of the routine.
I create it and us it.
Then I destroy it in the Finally section.
>
I use a Try Catch to capture and process any errors resulting from the use
of the form (or object).
I destroy the objects in the Finally section so that the code is run even
if
there is an error. If it was in the main Try section it may not be run.
>
However if the logic is used in VB2008 I get a warning saying I am using a
variable before it is assigned a value.
>
How do I ensure I cater for unexpected errors?
How do I declare my objects?
Do I destroy them or simple let GC do it.?
Your opinions please
>
--
Tim

For IDisposable objects, I recommend you dispose them whenever you
can. This topic is one of huge debate (Cor will be here shortly saying
the opposite of what I am) so I won't get into the why, but I'll
encourage you to search the archives for the discussions.

In your example, either of the below should work (I prefer the latter)

//////////////
Dim frmMyForm As MyForm = Nothing
Try
frmMyForm = New MyForm
frmMyForm.DoSom ething
Catch ex As Exception
ProcessError(ex )
Finally
If Not frmMyForm Is Nothing Then
frmMyForm.Dispo se()
frmMyForm = Nothing
End If
End Try
//////////////

//////////////
Try
Using frmMyForm As New MyForm()
frmMyForm.DoSom ething()
End Using
Catch ex As Exception
ProcessError(ex )
End Try
//////////////

Thanks,

Seth Rowe [MVP]

http://sethrowe.blogspot.com/

[Brian Gideon]

Re: Best Practice - Destroying objects

On Sep 13, 1:17 am, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

Tim
>
Finaly, is only a part of a try catch block, where finaly means that it
always is done as long as the computer is not unplugged.
>
Setting the reference of an object to nothing is absolute without any sense
in VB after VB6, simple because it does nothing more then an instruction to
set a memory address to all zeroes. The object still stays at the managed
heap until it is removed by the Garbage Collector.
>

It didn't make a whole lot of sense in VB6 either. When local
variables go out scope the object which was referenced had it's
reference count decremented anyway. Of course, you could force that
to happen sooner and in that respect it is a little different
situation.

You are nowhere destroying any object in your code. You use dispose whichas
Idispose is right implemtend releases all unmanaged resource used in your
object (as those are there). Dispose is a methode from components, while 20%
of the classes (especially controls) inherits that.
>
However, by instance in SharePoint and more classes, where the managed code
is only a wrapper around Com objects,  it is adviced to use dispose to
release those unmanaged resources.  If you are using SharePoint, then simple
invoke the dispose method to let the Idisposable section do its work.
Therefore it is by the SharePoint team called good practise to invoke
dispose at the end of every object (They have changed that text lately, it
is now more or less, good practise for Sharepoint objects).
>
Be aware that from the first day of managed code the dispose was seen as a
replacement for the deconstructor. In those days (and in non managed C++ but
not in Java) you should have used that deconstructor, therefore is in Java
and other managed languages like VB now the Garbage Collector. (And that is
in fact why it is called managed code).  Some people started paroting, that
it was good practise to use Dispose as the method was in a class, the same
as it is with non managed code good practise to descruct every object. There
are tons of pages on Internet where people are only telling that it is good
practise, but never tell why (or something as it does not harm).
>

It is a good practice because IDisposable *usually* implies that the
class holds unmanaged resources either directly or indirectly. Even
if the class didn't hold such resources it is still a good idea
because the class has basically warned you that they might add those
resources in the future.

By not calling Dispose you are relying on the GC to release the
resources when it runs the finalizers. The timing of that is
nondeterministi c and be *very* problematic in a number of situations.
That is one reason why it is a good practice.

To destroy an object is possible by using the deconstructor. However, it is
strongly adviced not to do that and let the Garbage Collector do its work..
>
Have a look at the designer code of a form (it is in more wizards), there
you see the implementation of the IDispose which is done at every close of a
form. If you create yourform yourself, then you have to implement this code
as well yourself to have benefit from the dispose. If you use objects which
implements very much handles like pens, then it is aviced to use then
dispose (to release the handles) everytime before there the object is
nowhere referenced anymore (and that is not only its own reference, that one
does as I started with, in this case nothing).
>
Cor
>

[Cor Ligthert[MVP]]

Re: Best Practice - Destroying objects

Brian,

Microsoft will never use in future a method in a class in another way then
it is now.
(Or it should be a new overload addition, but that does not affect current
code)

Do you use constantly GetHasCode and ReferenceEquals by the way, in the way
you write should that be forever used, because it is in every class.

However, I can assure you that this does not implies that you should use it,
it are simple inherited methods like ToString.

However if you want to use it, feel free, but don't paroting the "It is good
practise sentence, to give more and more the idea that it is true". In
German history (that is not mine), there was a guy who did the same and was
able to let millions of persons to be killed.

Cor

"Brian Gideon" <briangideon@ya hoo.comschreef in bericht
news:1ee8d798-6332-453e-bf20-574d719d764a@l4 2g2000hsc.googl egroups.com...
On Sep 13, 1:17 am, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

Tim
>
Finaly, is only a part of a try catch block, where finaly means that it
always is done as long as the computer is not unplugged.
>
Setting the reference of an object to nothing is absolute without any
sense
in VB after VB6, simple because it does nothing more then an instruction
to
set a memory address to all zeroes. The object still stays at the managed
heap until it is removed by the Garbage Collector.
>

It didn't make a whole lot of sense in VB6 either. When local
variables go out scope the object which was referenced had it's
reference count decremented anyway. Of course, you could force that
to happen sooner and in that respect it is a little different
situation.

You are nowhere destroying any object in your code. You use dispose which
as
Idispose is right implemtend releases all unmanaged resource used in your
object (as those are there). Dispose is a methode from components, while
20%
of the classes (especially controls) inherits that.
>
However, by instance in SharePoint and more classes, where the managed
code
is only a wrapper around Com objects, it is adviced to use dispose to
release those unmanaged resources. If you are using SharePoint, then
simple
invoke the dispose method to let the Idisposable section do its work.
Therefore it is by the SharePoint team called good practise to invoke
dispose at the end of every object (They have changed that text lately, it
is now more or less, good practise for Sharepoint objects).
>
Be aware that from the first day of managed code the dispose was seen as a
replacement for the deconstructor. In those days (and in non managed C++
but
not in Java) you should have used that deconstructor, therefore is in Java
and other managed languages like VB now the Garbage Collector. (And that
is
in fact why it is called managed code). Some people started paroting, that
it was good practise to use Dispose as the method was in a class, the same
as it is with non managed code good practise to descruct every object.
There
are tons of pages on Internet where people are only telling that it is
good
practise, but never tell why (or something as it does not harm).
>

It is a good practice because IDisposable *usually* implies that the
class holds unmanaged resources either directly or indirectly. Even
if the class didn't hold such resources it is still a good idea
because the class has basically warned you that they might add those
resources in the future.

By not calling Dispose you are relying on the GC to release the
resources when it runs the finalizers. The timing of that is
nondeterministi c and be *very* problematic in a number of situations.
That is one reason why it is a good practice.

To destroy an object is possible by using the deconstructor. However, it
is
strongly adviced not to do that and let the Garbage Collector do its work.
>
Have a look at the designer code of a form (it is in more wizards), there
you see the implementation of the IDispose which is done at every close of
a
form. If you create yourform yourself, then you have to implement this
code
as well yourself to have benefit from the dispose. If you use objects
which
implements very much handles like pens, then it is aviced to use then
dispose (to release the handles) everytime before there the object is
nowhere referenced anymore (and that is not only its own reference, that
one
does as I started with, in this case nothing).
>
Cor
>

[Brian Gideon]

Re: Best Practice - Destroying objects

On Sep 13, 1:01 pm, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

Brian,
>
Microsoft will never use in future a method in a class in another way then
it is now.
(Or it should be a new overload addition, but that does not affect current
code)
>
Do you use constantly GetHasCode and ReferenceEquals by the way, in the way
you write should that be forever used, because it is in every class.
>
However, I can assure you that this does not implies that you should use it,
it are simple inherited methods like ToString.
>
However if you want to use it, feel free, but don't paroting the "It is good
practise sentence, to give more and more the idea that it is true". In
German history (that is not mine), there was a guy who did the same and was
able to let millions of persons to be killed.
>
Cor
>

I don't know what to tell you that I haven't already in the past. If
a class implements IDisposable then assume it was put there for a
reason and call Dispose when you're done with it. The Framework
Design Guidelines book supports me on that point. I'd even rather see
someone do that across the board (i.e. DataSet) than not do it at all.

[Tom Shelton]

Re: Best Practice - Destroying objects

On 2008-09-13, Cor Ligthert[MVP] <notmyfirstname @planet.nlwrote :

Tim
>
Finaly, is only a part of a try catch block, where finaly means that it
always is done as long as the computer is not unplugged.
>
Setting the reference of an object to nothing is absolute without any sense
in VB after VB6, simple because it does nothing more then an instruction to
set a memory address to all zeroes. The object still stays at the managed
heap until it is removed by the Garbage Collector.
>
You are nowhere destroying any object in your code. You use dispose which as
Idispose is right implemtend releases all unmanaged resource used in your
object (as those are there). Dispose is a methode from components, while 20%
of the classes (especially controls) inherits that.
>
However, by instance in SharePoint and more classes, where the managed code
is only a wrapper around Com objects, it is adviced to use dispose to
release those unmanaged resources. If you are using SharePoint, then simple
invoke the dispose method to let the Idisposable section do its work.
Therefore it is by the SharePoint team called good practise to invoke
dispose at the end of every object (They have changed that text lately, it
is now more or less, good practise for Sharepoint objects).
>
Be aware that from the first day of managed code the dispose was seen as a
replacement for the deconstructor. In those days (and in non managed C++ but
not in Java) you should have used that deconstructor, therefore is in Java
and other managed languages like VB now the Garbage Collector. (And that is
in fact why it is called managed code). Some people started paroting, that
it was good practise to use Dispose as the method was in a class, the same
as it is with non managed code good practise to descruct every object. There
are tons of pages on Internet where people are only telling that it is good
practise, but never tell why (or something as it does not harm).
>
To destroy an object is possible by using the deconstructor. However, it is
strongly adviced not to do that and let the Garbage Collector do its work.
>
Have a look at the designer code of a form (it is in more wizards), there
you see the implementation of the IDispose which is done at every close of a
form. If you create yourform yourself, then you have to implement this code
as well yourself to have benefit from the dispose. If you use objects which
implements very much handles like pens, then it is aviced to use then
dispose (to release the handles) everytime before there the object is
nowhere referenced anymore (and that is not only its own reference, that one
does as I started with, in this case nothing).
>
Cor
>
>
>
"Tim Marsden" <tmqsl@newsgrou p.nospamschreef in bericht
news:B243FC1A-04B2-4DA5-9252-7F4CCB6ECD91@mi crosoft.com...

>Hi,
>I am after suggestions on the best practice declaring and destroying
>objects.
>>
>some example code:
>>
>Private Sub MySub
>>
> Dim frmMyForm As MyForm
>>
> Try
>>
> frmMyForm = New MyForm
> frmMyForm.DoSom ething
>>
> Catch ex As Exception
> ProcessError(ex )
> Finally
> If Not frmMyForm Is Nothing Then
> frmMyForm.Dispo se()
> frmMyForm = Nothing
> End If
> End Try
>End Sub
>>
>I declare my object (form in this case) at the beginning of the routine.
>I create it and us it.
>Then I destroy it in the Finally section.
>>
>I use a Try Catch to capture and process any errors resulting from the use
>of the form (or object).
>I destroy the objects in the Finally section so that the code is run even
>if
>there is an error. If it was in the main Try section it may not be run.
>>
>However if the logic is used in VB2008 I get a warning saying I am using a
>variable before it is assigned a value.
>>
>How do I ensure I cater for unexpected errors?
>How do I declare my objects?
>Do I destroy them or simple let GC do it.?
>Your opinions please
>>
>>
>>
>>
>>
>>
>>
>--
>Tim

>

--
Tom Shelton

[Bill McCarthy]

Re: Best Practice - Destroying objects


"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:urSdnRBW_c bw4VHVnZ2dnUVZ_ vqdnZ2d@comcast .com...

>
>
--
Tom Shelton

Yep ;)

[Tom Shelton]

Re: Best Practice - Destroying objects

On 2008-09-14, Bill McCarthy <Bill@localhost .comwrote:

>
"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:urSdnRBW_c bw4VHVnZ2dnUVZ_ vqdnZ2d@comcast .com...

>>
>>
>--
>Tom Shelton

>
>
Yep ;)
>

LOL... It was a mispost.

--
Tom Shelton

[Bill McCarthy]

Re: Best Practice - Destroying objects


"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:T5OdnTs8Pe _islDVnZ2dnUVZ_ hOdnZ2d@comcast .com...

On 2008-09-14, Bill McCarthy <Bill@localhost .comwrote:

>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:urSdnRBW_ cbw4VHVnZ2dnUVZ _vqdnZ2d@comcas t.com...

>>>
>>>
>>--
>>Tom Shelton

>>
>>
>Yep ;)
>>

>
LOL... It was a mispost.
>

<gYou should have said it was a practical demonstration: the post was set
to Nothing but there was still data there ;)

[=?Utf-8?B?VGltIE1hcnNkZW4=?=]

RE: Best Practice - Destroying objects

Guys,

Thanks for all your opinions it is very much appreciated. I am still a litle
confused. But to summarise:

Setting an object to nothing is NOT required.
Calling the dispose method is up for debate!
I am still unsure about using the Finally section to call the dispose to
ensure it is called if an error occurs.

Regards
Tim

[Tom Shelton]

Re: Best Practice - Destroying objects

On 2008-09-14, Tim Marsden <tmqsl@newsgrou p.nospamwrote:

Guys,
>
Thanks for all your opinions it is very much appreciated. I am still a litle
confused. But to summarise:
>
Setting an object to nothing is NOT required.

That's right.

Calling the dispose method is up for debate!

Not really. Cor is about the only one I know who holds the opinion
that it shouldn't always be called. This not meant as disrespect to Cor.

Cor is correct, in there are objects where it is unnecessary. They get the
method by virtue of inheriting from component (such as DataSet) or some other
base class - yet, there is no way (other then looking at the source) to know
for sure. Further, you can never be sure that the implementation may change
in the future in such a way that the call is necessary.

The point being, it's better safe then sorry.

I am still unsure about using the Finally section to call the dispose to
ensure it is called if an error occurs.
>

Personally, I wouldn't do that if your using VB2005 or latter. Just wrap it
in a using statement. Using will ensure that Dispose is called, even if an
error occurs. I tend to write the code like this:

Try
Using o As New SomeDisposableO bject()
o.DoCoolStuff()
End Using ' dispose always called - even if exception thrown
Catch e As Exception
' do stuff with exception
End Try

HTH

--
Tom Shelton

[Steve Gerrard]

Re: Best Practice - Destroying objects

Tim Marsden wrote:

Guys,
>
Thanks for all your opinions it is very much appreciated. I am still
a litle confused. But to summarise:
>
Setting an object to nothing is NOT required.
Calling the dispose method is up for debate!
I am still unsure about using the Finally section to call the dispose
to ensure it is called if an error occurs.
>
Regards
Tim

In your original posted code, if you changed the Dim statement to
Dim frmMyForm As MyForm = Nothing
then you would be fine and have no warnings.

The Using statement is another useful way to ensure disposal, for instance with
modal dialog type forms:
Dim frmMyForm As New MyForm
Using frmMyForm
' ... all processing, including any try/catch blocks
End Using

You don't set an object to Nothing, you set a particular reference variable to
Nothing. It is possible to have a dozen different reference variables all
referring to the same object.

If a reference variable is declared local (within a method), it will go out of
scope and be set to Nothing at the end of the method. If it is declared at
module level, however, that is not true, and you may want to explicitly set it
to Nothing when appropriate.

The garbage collector will call Dispose methods on objects that require it, if
it has not already been called. This takes two cycles of collection to
completely release an object. If an object uses significant resources and is no
longer needed, it may take some time for collection to release those resources.
In those cases, it is useful to explicitly call Dispose, so your app isn't
hogging stuff it doesn't need. Rather than check every type to see how
significant it is, many adopt the strategy of disposing everything that can be
disposed of as soon as they are done with it.