Are codes ran in try blocks expensive?

  • Thread starter Thread starter stktung
  • Start date Start date
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.
 
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]
 
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.
Click to expand...

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
 
Back
Top