Those two declarations don't do anything, so they can't throw an
exception..hence no need to wrap them in the try catch block. I haven't
looked at the IL, but I don't believe variable declaration are treated the
same..but I'm not sure, I'll have to get back to you.
In addition to performance, there are good reasons to only trap small bits
of code and in most instances, don't trap System.Exception except in
instances where you know you want to do so. If you had an OutOfMemory
Exception raised in that block, your routine would catch it. However, there
isn't much you are going to do programatically about this problem, and you
want to use exception handlers to respond to things are try to elegantly
recover. In general wrap risky code blocks,like Opening Database
connections or filestreams, where things beyond your code logic can cause
problems. There are other instances where things are very unlikely to occur
if you are careful coding like getting an OutOfRange exception in a loop.
If you carefully and liberally use Assertions in your test environment, you
can responsibly conclude that your code won't throw certain types of
exceptions, but this approach is not to say that you don't want to use
handlers at all.
In VB6 there was this ghastly construct called OnError Resume, and there
were a lot of progrrammers that thought this was all you need for exception
handling. In .NET, such a constrcut will work in VB.NET, but what it does
is wrap every single line of code in the block in it's own try catch
statement. This is awful for performance (not to mention that it can/does
cover up coding flaws). Most articles that I've read about not throwing
unneeded exceptions relate to people carelessly throwing out try catch
blocks, or intentionally raising an exception when an event would be much
more appropriate. For instance, in a BankAccount Class, if the user deducts
more than is avaialable, you could have a OverDrawn event that simply tells
the user this transaction won't work b/c the money isn't there. This is
pretty straightforward OO approach to such a problem. On the other hand,
you could throw a custom exception NotEnoughMoneyException. The problem
with the second approach is that A) You'd need to wrap your deposit function
with a try Catch to catch this, and that this isn't really an exception from
the compiler's point of view.
There are instances where you can just eat an exception, and it's ok to do
so. After all, the whole purpose of structured exceptions is to Handle
problems that you know can come up, and you can't necessarily preepmt with
your code.
If you follow John Robbins (the MSDN BugSlayer - buy his book if you don't
have it already), or Jeffrey Richter to use just two examples, they seldom
have more than a line of code wrapped in a try catch block. At most you
might see three or four but that is rare. Very precise, very targeted.
That is usually what most articles are advocating when they mention this.
HTH,
Bill
