Are .NET try / catch cheap?

Question

Possible Duplicate:
Performance Cost Of 'try'

I stumbled upon this remark in "Best Practices for Handling Exceptions" at MSDN:

" using exception handling is better because less code is executed in the normal case"

in the context of whether one should check for the state of an object before calling a method or just call the method and catch the exception. The above recommendation is when the event of an exception is rare.

Assuming the property check will not imply a costly calculation, but merely return a state value, how cheap is the execution cost of a try / catch block in the non-throwing case compared to a property check?

I am wondering about the recommendation, because even if the try / catch is free or near free, the called method will in many cases do a bunch of checks by it's own.

Answer 1

Exceptions in .NET are very cheap unless they are raised. As soon as you raise an exception, the effective cost goes up quite a bit.

That being said, I'd strongly recommend programming to the most maintainable solution here, and worrying about the performance later if, and only if, it's proving to be a problem after measurement.

A property get method which just returns state is optimized to be a field lookup, and is pretty much a single operation - anything will typically be slower than that later. However, I doubt that exception handling will cause any noticeable effect in your overall speed unless it's in a very, very tight loop - in which case, the overall performance will likely not be worse than the checks you'd introduce to avoid the exception handling.

Answer 2

"Exceptions are for exceptional situations", not for normal control flow.

IME, C# exceptions can add a noticeable performance penalty when you're catching thousands of them in a loop for instance.

Answer 3

Typically, exception handling mechanisms are designed with the intention that trying is cheap and throwing is expensive. However, exceptions are certainly more costly than most other operations. Avoiding a throw wherever possible is the most performant solution and if you can take for example a simple if statement instead of using an exception, do.

Answer 4

You are taking the quote out of context. The full quote is (emphasis mine):

If the event is truly exceptional and is an error (such as an unexpected end-of-file), using exception handling is better because less code is executed in the normal case. If the event happens routinely, using the programmatic method to check for errors is better. In this case, if an exception occurs, the exception will take longer to handle.

The overhead from exception handling comes from actually catching an exception. If an exception is not thrown/caught, it's relatively cheap.

The above quote's logic is as follows:

• If you are repeating the operation a number of times and it's not reasonable for the exception to occur, then don't perform the check, use the exception. You are saving code cycles by not repeating the check every iteration.

• If the operation does not cycle over and over, then check the condition instead of catching the exception.

The first point could be considered a case of premature optimization, but there is validity to the point, however, it should only be for an exceptional case (no pun intended).

Generally, you will want to do as the article suggests and check against some state instead of relying on exception handling.

Answer 5

The other advantage to using try/catch is that it allows you to centralize your error handling in one block, especially when there are multiple causes in your function that might raise an exception. If you don't need to handle each case differently, it makes sense to have one try/catch for all those calls, so that the exception handling can be centralized.

More importantly, it allows you to use finally, which is very powerful for ensuring that resources are properly cleaned up whether the exception is raised or not.