SYSK 362: The cost of try/catch

Since I’m still coming across a lot of conflicting recommendations on the “best practices for structure exception handling” (including those coming from different folks from Microsoft), I decided to write a blog post on the topic.

 

So, what are the benefits and costs with SEH?

 

Let me first address the cost of adding try/catch/finally…

 

John Lee (a peer MCS consultant) did some profiling on his HP Compaq nc8430 Laptop (Dual Core CPU 2.16GHz, 4GB RAM) and, using that hardware, the approximate overhead of adding try/catch per function when exception is not thrown is 0.00001235 ms. In comparison, getting a connection from a connection pool takes 0.0409662 ms => over 3,000 times slower. If an exception is thrown from a function nested 10 levels deep with try/catch and rethrow at every level, then the execution time goes up to 0.02010861 ms.

 

Using the numbers above, in my opinion, the cost of try/catch (especially given that, in most cases, the code runs successfully without incurring the cost of throwing an exception) in the context of creating business applications (I’m not talking about critical, real-time or near real time apps which most likely are not written in .NET anyway), is so negligible that the benefits (see next paragraph) far outweigh the cost.

 

As to the benefits… In my projects, in addition to the standard call stack info, I add the actual data passed to each function in the faulting call stack to the exception message eventually logged to a database. In most cases, this gives me sufficient data to recreate the problem and do root cause analysis in a fraction of the time it would take without such details.

 

In summary, if a method can either handle the exception (e.g. correct the problem and/or retry) or has other value-add (e.g. log passed in parameter values in the catch block), then the value of sprinkling the try/catch in every single method (not just at the top-most level) in business level applications is significantly greater, in my opinion, then the cost of the try/catch statements.

 

 

Special thanks to John Lee for doing the profiling!

Comments

• Anonymous
  October 12, 2007
  PingBack from http://www.artofbam.com/wordpress/?p=7937

• Anonymous
  October 12, 2007
  First off, these sort of tests that run in isolation may not always be as representing as you wish them to be. There are so many other factors that these results could be down-right misleading. While I agree that generally speaking the cost is dwarved when compared to other stuff you do, you should be very careful with this sort of blanket statement. What if you have a property/getter that return the state of a boolean? What if that gets called in a tight loop? What if somebody read your blog and decided to use throw to represent a value? A very small and not-represneting case shows that in those cases, the cost becomes more apparent - something around 33% slower to run the method with a try/catch/finally than w/o. Again, I agree with the main part of your conclusion, but as a rule of thumb, not as a "catch all" thing.

• Anonymous
  October 12, 2007
  Totally agreed.  Thanks for the post.

• Anonymous
  October 12, 2007
  first, thanks for the post. always good to see some data on stuff like this. in my experience, the cost of try/catch is much more noticeable in ASP.NET apps. this is due, i think, to the work the asp.net runtime must do to clear pending requests from the stack when an exception is reported. also, i see many cases where programmers actually rely on exceptions to handle branching tasks (try add-user, if exception=='user-exists' then update-user). so, even when the cost is minimal, SEH should be used wisely.