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.
Comments