Home All Groups Group Topic Archive Search About

Are codes ran in try blocks expensive?

Author
25 Aug 2006 8:16 PM
stktung
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/ExceptionsAndErrorCodes.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

Author
25 Aug 2006 8:40 PM
Marina Levit [MVP]
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.

<stkt***@yahoo.com> wrote in message
Show quoteHide quote
news:1156536967.266667.314860@i42g2000cwa.googlegroups.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/ExceptionsAndErrorCodes.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
>
Author
27 Aug 2006 8:31 AM
Michel Posseth [MCP]
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]



Show quoteHide quote
"Marina Levit [MVP]" <someone@nospam.com> schreef in bericht
news:%231GwuaIyGHA.4024@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.
>
> <stkt***@yahoo.com> wrote in message
> news:1156536967.266667.314860@i42g2000cwa.googlegroups.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/ExceptionsAndErrorCodes.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
>>
>
>
Author
28 Aug 2006 2:11 PM
Jim Wooley
> 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