Performance cost of a try/catch block [duplicate]

Question

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?

Answer 1

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.

Also see these related SO questions: (1) (2) (3) and (4).

Answer 2

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.

Answer 3

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.