Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I came across this example recently:

If 999 times out of 1,000 an exception will not be thrown then the exception is only generated once. On the other hand a conditional would have been called needlessly 999 times, therefore in this case the exception is superior.

In this instance it's C#, but generally speaking is this true? I had previously assumed try/catch statements had their own overhead that would equal the time spent handling a conditional.

Granted, just throwing try/catch blocks anyplace a conditional would normally go would be a terrible way to code, but resource-wise does this statement hold up?

share|improve this question
How does the compiler implement try/catch? I suspect it's a bit more complicated than a simple if(). – Dan Pichelman Apr 25 '13 at 13:49
Try it out. Really, try it out. Why would you believe something some random person on the internet said? Knowing how common elements in your language of choice compare performance-wise is well worth the limited effort of performing a careful experiment, once. – Kilian Foth Apr 25 '13 at 14:05
I felt writing a performance comparison is a very easy task to mess up, especially an abstract one; also the example is from a C# textbook – Bob Apr 25 '13 at 14:24
I'll make the requisite "write readable code and don't premature optimize" comment. – djechlin Apr 25 '13 at 14:29
@djechlin Someone had to ; ) – Bob Apr 25 '13 at 14:38
up vote 4 down vote accepted

It's generally true for commercial-quality compilers. However, conditionals may achieve similar efficiencies using assume(false)-style annotations. Profile Guided Optimization may beat both.

The underlying reason is that good compilers can generate more efficient code by making correct assumptions about the likelyhood of code being executed. Since the convention is that exceptions are exceptional, most compilers (in the absence of profiling data) will generate code that is optimal when exceptions are indeed rare.

For instance, the exception-handling code may be put in its own segment, and only be paged in when the first exception occurs. This means the CPU cache can be used more efficiently, storing only non-exceptional code.

share|improve this answer
And dynamic compilers, such as for example found in almost all JavaScript engines, JVMs, and Smalltalk implementations, don't even need to make assumptions about the likelihood of branches, they can just count them. That's like PGO on steroids: re-profiling and re-optimizing over and over and over and over again, using the real workload that is executing right now to guide optimizing the code that is executing right now. – Jörg W Mittag Apr 25 '13 at 15:30

There are scenarios to use try/catch and others to use conditionals.

Using a try/catch does not harm performance as outlined extensively Here

The overall cost of a try...catch block that never handles an exception is a few bytes of memory

Beyond performance, proper exception handling is important. The last thing you want is uncaught errors being shown to a user, buggy performance or the application hanging after an issue is encountered.

share|improve this answer
+1 performance isn't the only important thing to worry about or we would ditch user friendly graphical interfaces in an instance – RhysW Apr 25 '13 at 14:15
That's a great read regarding exceptions. – Bob Apr 25 '13 at 14:36

An example of a better performance using try/catch instead of a conditional is when dealing with Dictionaries, when asking if contains the key is O(n) versus just try to access/add the key and catch the potential exception.

    dict.Add(key, val);
catch (Exception)

    dict[key] = val;
share|improve this answer
Wow, if this is true I'm really surprised! Do you have a reference? – user39685 Apr 25 '13 at 15:14
-1. Don't do this. If you're concerned about the performance overhead of checking if the key exists, then use TryGetValue() instead. – Stargazer712 Apr 25 '13 at 15:26
thanks for pointing that, the least I want is to advise a bad practice. I've been using this for a long time though, good habbit that became obsolete I guess. Anyway my point was to show there are scenarios when catching an exception might be an option better than asking if is valid to do something. – Enrique Medina Apr 26 '13 at 12:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.