Problem :
Possible Duplicate:
Performance Cost Of ‘try’
I am being told that adding a try catch block adds major performance cost in the order of 1000 times slower than without, in the example of a for loop of a million. Is this true?
Isn’t it best to use try catch block as much as possible?
Solution :
From MSDN site:
Finding and designing away
exception-heavy code can result in a
decent perf win. Bear in mind that
this has nothing to do with try/catch
blocks: you only incur the cost when
the actual exception is thrown. You
can use as many try/catch blocks as
you want. Using exceptions
gratuitously is where you lose
performance. For example, you should
stay away from things like using
exceptions for control flow.
I could swear there was a question like this just a few days ago, but I can’t find it…
Just adding a try/catch block is unlikely to change the performance noticeably when exceptions aren’t being thrown, although it may prevent a method from being inlined. (Different CLR versions have different rules around inlining; I can’t remember the details.)
The real expense is when an exception is actually thrown – and even that expense is usually overblown. If you use exceptions appropriately (i.e. only in genuinely exceptional or unexpected error situations) then they’re unlikely to be a significant performance hit except in cases where your service is too hosed to be considered “working” anyway.
As for whether you should use try/catch blocks as much as possible – absolutely not! You should usually only catch an exception if you can actually handle it – which is relatively rare. In particular, just swallowing an exception is almost always the wrong thing to do.
I write far more try/finally blocks (effectively – almost always via using statements) than try/catch blocks. Try/catch is sometimes appropriate at the top level of a stack, so that a service can keep processing the next request even if one fails, but otherwise I rarely catch exceptions. Sometimes it’s worth catching one exception in order to wrap it in a different exception – basically translating the exception rather than really handling it.
You should definitely test claims like this (easy enough), but no, that isn’t going to hurt you (it’ll have a cost, but not 1000’s of times).
Throwing exceptions and handling them is expensive. Having a try..catch..finally isn’t bad.
Now with that said, If you are going to catch an exception, you need to have a plan for what you are going to do with it. There is no point in catching if you are just going to rethrow, and a lot of times, there’s not much you can do if you get an exception.
Adding try catch blocks helps control your application from exceptions you have no control over. The performance cost comes from throwing an exception when there are other alternatives. For example throwing an exception to bail out of a routine instead of simply returning from a routine causes a significant amount of overhead, which may be completely unnecessary.
I am being told that adding a try
catch block adds major performance
cost in the order of 1000 times slower
than without, in the example of a for
loop of a million. Is this true?
Using try catch adds performance cost, but it isn’t a major performance cost.
Isn’t it best to use try catch block
as much as possible?
No, it is best to use try catch block when makes sense.
Why guess at the performance costs, when you can benchmark and see if it matters?
It’s true that exceptions a very expensive operation. Also try..catch blocks clutter the code and make it hard to read. That said exceptions are fine for errors that should crash the application most of the time.
I always run on break on all exceptions, so as soon as an error happens it throws and I can pinpoint it fairly easy. If everyone is throwing exceptions all the time I get bad performance and I can’t use the break on all exceptions, that’s makes me sad.
IMO don’t use exception for normal program events (like user types in a non-number and you try to parse it as a number). Use the normal program flow constructs for that (ie if).
If you use functions that may throw you make a choice. Is the error critical => crash the app. Is the error non-critical and likely => catch it (and potentially log it).