Code Standard 2.0 new objects outside of Try Block

  • Thread starter Thread starter gabe
  • Start date Start date
G

gabe

I have question about code standards in VS 2005

I have been declaring objects before a try block in case I would ever
want to refer to them in 'Catch' block. When I converted my apps to 2.0
I get warnings that objects have been declared, but not initialized.
I've hesitated to actually 'New' an object outside of a try in the
event of an exception occurring. For example, if I new up a Connection
object with a connection string with an incorrect syntax it will throw
an InvalidArgument exception.

What's a best practice for this?

(I don't use Try Blocks in every method, but when I do, I want to make
sure that things are being trapped)

Thanks,

Gabe
 
Gabe,

Just assign null to the variables - this should stop those warnings. You
don't necessarily have to instantiate the objects.

I have question about code standards in VS 2005

I have been declaring objects before a try block in case I would ever
want to refer to them in 'Catch' block. When I converted my apps to 2.0
I get warnings that objects have been declared, but not initialized.
I've hesitated to actually 'New' an object outside of a try in the
event of an exception occurring. For example, if I new up a Connection
object with a connection string with an incorrect syntax it will throw
an InvalidArgument exception.

What's a best practice for this?

(I don't use Try Blocks in every method, but when I do, I want to make
sure that things are being trapped)

Thanks,

Gabe
 
I believe you'll want to create these objects within the Try/Catch block so that
they are available within the block and then immediately disposed when the block
is exited.

Warnings are just that, they don't necessarily mean the code is going to crash.
 
Gabe

Are you sure that the variables are real usable or/and used.
Setting them to null is just a waste of processing time in my opinion.
(I assume you are using VB.Net, were we (regulars from VBNet language
newsgroup) hope that this warnings will be more selective in future as it is
now very much based on C# coding)

Cor
 
I do this too - set the variables to null.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Accept the Unexpected.
 
Thanks --- I'll follow that advice.

I was thinking in 1.1 that only class member variables were't
initialized. I'll run it through the debugger to verify, but I'll Null
them anyway to satisfy the compiler.
 
My take on it would be something like:

private sub xyz

dim a as object
try
a = new (object)
a.blahblah...

catch
end try
end sub

it keeps all the variable declarations together at a place, however you
instantiate the object only when it is required.
Flipside from this is of course that the object lifeline gets extended a wee
bit longer than it would be if you were to declare it within a try catch
block inside an if construct or some loop.
But then it would not be too advisable to have really long methods anyway.
The object does get collected once the method is executed.

HTH
Nick
 
Back
Top