8

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?

7
  • How does the compiler implement try/catch? I suspect it's a bit more complicated than a simple if(). Apr 25 '13 at 13:49
  • 8
    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. 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
    – Jane Panda
    Apr 25 '13 at 14:24
  • 2
    I'll make the requisite "write readable code and don't premature optimize" comment.
    – djechlin
    Apr 25 '13 at 14:29
  • 1
    @djechlin Someone had to ; )
    – Jane Panda
    Apr 25 '13 at 14:38
4

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.

1
  • 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. Apr 25 '13 at 15:30
4

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.

2
  • 3
    +1 performance isn't the only important thing to worry about or we would ditch user friendly graphical interfaces in an instance
    – user78252
    Apr 25 '13 at 14:15
  • 2
    That's a great read regarding exceptions.
    – Jane Panda
    Apr 25 '13 at 14:36
-1

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.

try
{
    dict.Add(key, val);
}
catch (Exception)
{

    dict[key] = val;
}
3
  • Wow, if this is true I'm really surprised! Do you have a reference?
    – user39685
    Apr 25 '13 at 15:14
  • 5
    -1. Don't do this. If you're concerned about the performance overhead of checking if the key exists, then use TryGetValue() instead. msdn.microsoft.com/en-us/library/bb347013.aspx
    – riwalk
    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. Apr 26 '13 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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