By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,402 Members | 1,101 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,402 IT Pros & Developers. It's quick & easy.

Try... Catch performance

P: n/a
Hi.

I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that
won't help me at all?

TIA,
Erik Cruz
Nov 22 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
No. The expensive thing is raising an exception. While an exception is
not raised, there is not performance penalty. (at least not
considerably)

On Sat, 18 Oct 2003 17:02:03 -0300, "Erik Cruz"
<er******************@antares.com.br> wrote:
Hi.

I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that
won't help me at all?

TIA,
Erik Cruz


Nov 22 '05 #2

P: n/a
Try...Catch is only needed around code that could throw an exception. So,
if you have lots of code that does very simple work, but only one line that
could throw an exception, you normally would just wrap the one line in the
exception and catch only the exception that you are concerned with.

Exceptions are expensive when thrown, but only when thrown. That is the key
point. Simply having code within a try block does not necessarily make your
code run slower. If you wrap code that never throws an exception in a try
block, it will run just as fast as if there was no try block.

Also, unless you have reason to, you might want to limit your catch
statement to specific exceptions. Catching the base Exception is usually
not done and offers little help when analyzing what happened.

"Erik Cruz" <er******************@antares.com.br> wrote in message
news:#c**************@TK2MSFTNGP11.phx.gbl...
Hi.

I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that
won't help me at all?

TIA,
Erik Cruz

Nov 22 '05 #3

P: n/a
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
"Erik Cruz" <er******************@antares.com.br> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Hi.

I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that
won't help me at all?

TIA,
Erik Cruz

Nov 22 '05 #4

P: n/a
> 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.
This is probably not a realistic case, but will throw an exception ......

Dim a As Int32
a = 45000

Dim b As Int16 = a

Bob Lehmann

"William Ryan" <do********@comcast.nospam.net> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl... 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
"Erik Cruz" <er******************@antares.com.br> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Hi.

I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that won't help me at all?

TIA,
Erik Cruz


Nov 22 '05 #5

P: n/a
Point taken, I should have been more clear. An initialization coupled with
a Declaration could possibly throw an exception, but I don't think a simple
declaration could.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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.


This is probably not a realistic case, but will throw an exception ......

Dim a As Int32
a = 45000

Dim b As Int16 = a

Bob Lehmann

"William Ryan" <do********@comcast.nospam.net> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...
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
"Erik Cruz" <er******************@antares.com.br> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Hi.

I have read several articles recommending avoid to raise exceptions when possible, since exceptions are expensive to the system. Removing code

from Try... Catch blocks can help performance? The following 2 first lines of code - I think - can't raise exceptions:

Try
Dim str As String
Dim intVar As Integer
'More code here

Catch Ex As Exception

End Try

Should I remove the variable declarations from the Try block or doing that won't help me at all?

TIA,
Erik Cruz



Nov 22 '05 #6

P: n/a
All declarations will be for the method in the IL anyways. A declaration
doesn't do anything except make IL emit the .locals(whatever, whatever,
etc.).
-mike
MVP

"William Ryan" <do********@nospam.comcast.net> wrote in message
news:uo**************@TK2MSFTNGP11.phx.gbl...
Point taken, I should have been more clear. An initialization coupled with a Declaration could possibly throw an exception, but I don't think a simple declaration could.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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.
This is probably not a realistic case, but will throw an exception .......

Dim a As Int32
a = 45000

Dim b As Int16 = a

Bob Lehmann

"William Ryan" <do********@comcast.nospam.net> wrote in message
news:OO**************@TK2MSFTNGP12.phx.gbl...
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
"Erik Cruz" <er******************@antares.com.br> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
> Hi.
>
> I have read several articles recommending avoid to raise exceptions when > possible, since exceptions are expensive to the system. Removing
code from
> Try... Catch blocks can help performance? The following 2 first
lines
of > code - I think - can't raise exceptions:
>
> Try
> Dim str As String
> Dim intVar As Integer
> 'More code here
>
> Catch Ex As Exception
>
> End Try
>
> Should I remove the variable declarations from the Try block or

doing that
> won't help me at all?
>
> TIA,
> Erik Cruz
>
>



Nov 22 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.