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
"Cor Ligthert [MVP]" wrote:
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
"gabe" <ga*****@gmail.comschreef in bericht
news:11*********************@i3g2000cwc.googlegrou ps.com...
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
