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

Are codes ran in try blocks expensive?

P: n/a
Hi,

I'm not too familiar with how exception works in .NET but I've read
from somewhere that in C++, code that are ran in try blocks are
expensive:

http://gamearchitect.net/Articles/Ex...rrorCodes.html

Is it the same for .NET? or .NET implements a Zero Overhead Exception
Handling (as mentioned in the article) that makes codes ran in the try
block essentially free?

-stung

Aug 25 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I believe there is a cost associated with the, but it is very very small, as
long as no exception is thrown. If an exception is thrown, then there is a
higher cost.

This cost should not prevent you from putting try/catch blocks where
necessary. If you have performance problems in your application, it is not
because you have one too many try/catch blocks.

<st*****@yahoo.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...
Hi,

I'm not too familiar with how exception works in .NET but I've read
from somewhere that in C++, code that are ran in try blocks are
expensive:

http://gamearchitect.net/Articles/Ex...rrorCodes.html

Is it the same for .NET? or .NET implements a Zero Overhead Exception
Handling (as mentioned in the article) that makes codes ran in the try
block essentially free?

-stung

Aug 25 '06 #2

P: n/a
My experience is that they are indeed expensive....

a general rule of thumb is to check for wrong values instead of writing a
try catch construct when this is possible

in all other situations use a try catch construct

hth

Michel Posseth [MCP]

"Marina Levit [MVP]" <so*****@nospam.comschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
>I believe there is a cost associated with the, but it is very very small,
as long as no exception is thrown. If an exception is thrown, then there is
a higher cost.

This cost should not prevent you from putting try/catch blocks where
necessary. If you have performance problems in your application, it is not
because you have one too many try/catch blocks.

<st*****@yahoo.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...
>Hi,

I'm not too familiar with how exception works in .NET but I've read
from somewhere that in C++, code that are ran in try blocks are
expensive:

http://gamearchitect.net/Articles/Ex...rrorCodes.html

Is it the same for .NET? or .NET implements a Zero Overhead Exception
Handling (as mentioned in the article) that makes codes ran in the try
block essentially free?

-stung


Aug 27 '06 #3

P: n/a
I believe there is a cost associated with the, but it is very very
small, as long as no exception is thrown. If an exception is thrown,
then there is a higher cost.

This cost should not prevent you from putting try/catch blocks where
necessary. If you have performance problems in your application, it is
not because you have one too many try/catch blocks.
It might not be because you have one too many Try blocks, but could be if
you have too many catch blocks. Consider the following mechanism used in
VB 8.x if you don't use the built-in IsNumeric function:

Public Shared Function IsInteger(input as object) as Boolean
Try
Integer.Parse(input)
Catch
Return False
End Try
Return True
End Function

What is really exceptional about this one is that internally, Integer.Parse
contained a try catch block which threw an exception as well which the framework
swallowed and re-threw. Now, if we loop through a table of 10,000 records
and call our IsInteger on a field, we will catch 20,000 exceptions just to
find out if it is indeed a number.

Luckily the framework team recognized the issue and fixed it with TryParse.
The resulting performance is drastically improved even with the amount of
byte parsing that occurs under the covers.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Aug 28 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.