Does try { } catch make program slower?

[Panathinaikos22]

Does try { } catch make program slower?

I think only if code on try fail will take a little more timebecause will run catch also... idk
what you say;

[deceptikon]

Does try { } catch make program slower?

No. There's a performance hit to actually throwing an exception, but if you don't catch it, it'll just propagate up and potentially be unhandled. In the case of exceptions you have no control over such as the standard or third party libraries, there's really no option but to catch it somewhere. For exceptions you yourself throw, that's where the guidelines of only throwing an exception where it's truly appropriate come in (because there's a performance cost when you throw). ;)

[SyncMaster170]

try catch block does not slow down your program at all and is basically a standard for catching exceptions. Try Catch statements is basically your safe net when it comes to bugs in your code/program. Without them, it would be fairly hard to know why your program is all of a sudden crashing or not performing a calculations correctly.

[DavidKroukamp]

heres 2 good links: http://stackoverflow.com/questions/161942/how-slow-are-net-exceptions and http://stackoverflow.com/questions/615955/under-c-sharp-how-much-of-a-performance-hit-is-a-try-throw-and-catch-block

[sknake]

The above answers are 'technically' incorrect (but deceptikon did a great job explaining it). Exceptions are very expensive to be thrown, but are of little cost to be caught (not no cost). This is especially noticeable if they are thrown in code that is commonly called (painting, calculations, etc).

try..catch{} is not your safety net for bugs in your program. If an exception is thrown, caught and the program continues you are just as likely to introduce a bug as you are to solve one. Albeit the application might not crash but the output might not be correct. For example if you have code to calculate some metric that runs in a loop and it throws an exception half way through, which you handle, and subsequently abort the calculation and display output to the user -- yes it did not crash, but it is not correct either. I prefer crashing exceptions. They're easier to hunt down than incorrect logic bugs.

Additionally you have compiler optimizations (f.ex. inlining and tail calls). Those optimizations are not emitted by the compiler if the method in question contains a try..catch{} block.

The bottom line is catching exceptions causes certain compiler optimizations not to take place which slightly reduce performance. The real performance issue is exceptions being thrown in the first place -- code around it where you can.

See this article:
http://stackoverflow.com/questions/5708063/can-i-stop-net-4-performing-tail-call-elimination