Garbage Collection

I've been wondering about something now that I've done a bit in .NET. How reliable is the garbage collection?

In a sub, I could create a command, a dataset, a datareader, a new form, etc. Then at the end of the sub, what happens if I do not dispose of them? In C++ (unmanaged) you get a memory leak if you use New to acquire memory, and fail to free it up after you are done with it. New doesn't seem to serve the same purpose in .NET, but in some cases it serves a similar purpose.

Is it simply good practice to dispose of locally declared (dimmed) variables, or is it necessary to avoid memory leaks?

Some people manually .Dispose() everything, no matter how small. I don't, even though my apps tend to stay open on the user's desktop all day long. I haven't noticed a memory leak problem ever, and about half of my user's desktops have only 64 or 128mb of RAM - the rest have 256.

The issue I run into is that if I were to create a command and then try to create a datareader both within a Try block, and an exception gets thrown.

At that point, there are a couple of things that could have thrown exceptions.

One option would be to try to figure out from the type of exception exactly where the exception was thrown, and determine from that whether or not the command needs to be disposed, but that seems to be an incomplete solution, because that would require that you deal with every possible exception that could arise. I don't believe I have that list.

Another option, and one I have used, would be to check to see if the component is nothing, and dispose of it if need be in a Finally block.

A third option is to handle each risky step within it's own Try block, but that has other issues.

What I'd like to do is just to ignore locally declared variables, and let them be cleaned up as they go out of scope, but I'm not sure how such a practice would be received, and whether or not it is safe.

GC is safe and reliable in .NET.

Read this:

http://msdn.microsoft.com/msdnmag/issues/1100/GCI/

I usually declare my objects outside the Try Catch block, btw. Insantiation within or outside.
Main potentionally-error-prone operations within the Try Catch block.
Clean up in the Finally area, so that I get rid of them anyways.

Legal.

Memory leaks are a thing of the past apparently.

Well then, I may just get a bit lazy.

Is there ever a time in .NET when you cannot have something throw an error? You could put a Try...Catch within a Catch block to trap an error, but is there a place where you can't live with an error?

It seems like the problems with constructors throwing errors that exist in C++ would also apply to VB.NET. Should you utterly avoid having the sub New raise an error?

in the sticky at the top of the forum the 101 vb.net samples has a garbage collection example.

BTW, objects that implement a dispose method, do so because the GC doesn't automatically reclaim the resources used by these objects, therefor once you are done with them you should ALWAYS call dispose

Bummer. Just what I didn't want....a voice of reason:(

Ok, I guess that's what I needed to hear.