Exceptions and Performance in .NET

So Should I Throw Millions Of Exceptions?

My rebuttal of the claims of the cost of exceptions has sometimes been misinterpreted as a belief that exceptions should be used anywhere and everywhere, and that you shouldn't be worried if your application throws millions of them. This is not the case - I merely think that in almost every situation where the performance of exceptions would be significant, there are bigger design problems to worry about. While it really wouldn't matter in performance terms if every so often you threw several thousand exceptions in a second, it would be suggestive of a situation where either exceptions shouldn't be used, or the first exception should have triggered a back-off of some description.

As an example of the first, if you're trying to parse a huge list of strings which were meant to be integers, knowing in advance that many of them wouldn't be valid integers to start with, it would be wise to use some kind of validation prior to the actual parsing. (For simplicity, the validation would probably only want to be a very simple filter which weeded out obviously bad data - you'd still want to handle a possible exception in the real parsing.) Alternatively, if a suitable library call were available, you could use a version which didn't throw exceptions: in .NET 2.0, for example, each of the numeric types has a TryParse method for precisely this kind of situation.

As an example where back-off (or indeed total failure) should be used, you shouldn't have a loop which constantly tries to access a database, retrying the same operation again eternally if something goes wrong. Here, using exceptions is the right way of indicating that something has failed, but you'd want to put some kind of limited retry mechanism in, with the overall operation failing if any part failed more than three times, or something similar. Whether that overall operation then goes into a retry state (after a suitable back-off delay) or whether it's aborted permanently depends on the situation - but changing the interface not to use exceptions to indicate failure wouldn't help anything, and would just make the error handling more complicated.

This article isn't meant to be an in-depth style guide for exceptions - there are many, many articles on that topic, and frankly I'm not sufficiently convinced that I have "the right answer" to try to write another one. The crucial point is that although exceptions are indeed slower than simply returning an error code, unless you are abusing exceptions to start with, you're very, very unlikely to find that exceptions are a performance bottleneck. When designing the contract of a method, it's worth considering whether it's reasonable to call that method in a fairly tight loop, continuing to call it even if the previous call fails. In that case, it may be worth having two methods, one of which uses exceptions to indicate errors and one of which doesn't (like Parse and TryParse) but in all other situations, using exceptions is unlikely to cause performance problems, but is likely to make the calling code much easier to understand.

You might also like...


About the author

Jon Skeet United Kingdom

C# MVP currently living in Reading and working for Google.

Interested in writing for us? Find out more.


Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“There are 10 types of people in the world, those who can read binary, and those who can't.”