Using "catching exceptions" to improve readability, Good or Bad?

Question

In the section When to Use Exception in The Pragmatic Programmer, the book writes that instead of:

retcode = OK;
     if (socket.read(name) != OK) {
      retcode = BAD_READ;
    }
     else {
      processName(name);
       if (socket.read(address) != OK) {
        retcode = BAD_READ;
      }
       else {
        processAddress(address);
         if (socket.read(telNo) != OK) {
          retcode = BAD_READ;
        }
         else {
          //  etc, etc...
        }
      }
    }
     return retcode;

, they prefer:

 retcode = OK;
     try {
      socket.read(name);
      process(name);
      socket.read(address);
      processAddress(address);
      socket.read(telNo);
      //  etc, etc...
    }
     catch (IOException e) {
      retcode = BAD_READ;
      Logger.log( "Error reading individual: " + e.getMessage());
    }
     return retcode;

simply because it looks neater. I'm all for neater code, however isn't unnecessary catching of Exceptions a performance bottleneck?

I can understand that we should give up minuscule optimization for neater code (at least 99% of the times), however from what I know, catching exceptions belong to the class of code which have a noticeable delay in runtime. Hence I was wondering what's the justification that the second piece of code is preferred over the first code?

Or rather, which code would you prefer?

Answer 1

Exceptions are typically only slower if they actually thrown. Usually, the exceptions in situations like this are rare so its not something you should worry about. You should only really worry about the performance of exceptions if they are happening all the time and thus are a significant factor.

The second code is better because its much easier to follow the logic. The error handling is nicely localised. The only objection is that if you are using exceptions, then use exceptions. Don't catch the exceptions and then return an error code.

Answer 2

Well, as they also say, exceptions should handle the exceptional cases, and since this is an exceptional case (i.e. something that happens few and far in between) I'd say that this applies here as well.

Also, I'd advise against micro-optimizing things such as this. Focus more on the readability of the code, since you'll be spending far more time reading code than writing new code.

To really make sure that this is a performance bottleneck, do some profiling, and analyze and focus on the more critical tasks based on that analysis.

Answer 3

I can understand that we should give up minuscule optimization for neater code (at least 99% of the times), however from what I know, catching exceptions belong to the class of code which have a noticeable delay in runtime.

Where do you know that from? How do you define "noticeable delay"?

This is exactly the kind of vague (and completely wrong) performance myth that leads to useless premature optimizations.

Throwing and catching an exception may be slow compared to adding two numbers, but it's completely insignificant compared to reading data from a socket. You could probably throw and catch a thousand exceptions in the same time you've read a single network packet. And we're not talking about thousands of exceptions here, only a single one.

Answer 4

I'd agree with the answers you've already gotten saying that this is an exceptional case, so it's reasonably to use exception handling.

Addressing your performance concerns more directly, I think you need to keep a sense of scale about things. Throwing/catching an exception under these circumstances is likely to take one the order of a microsecond. As flow control goes, that's slow -- many times slower than normal if statements, no question about that.

At the same time, keep in mind that what you're doing here is reading data from a network. At 10 megabits per second (slow for a local network, but pretty fast as Internet connections go), that's on the same order as the time to read one byte of information.

Of course, that overhead is only incurred when you actually throw the exception as well -- when it's not thrown, there's usually little or no overhead at all (at least from what I've seen, the most significant overhead isn't from the exception handling itself, as from adding more potential flows of control, making the code harder for the compiler to optimize quite as well).

In this case, when an exception is thrown, your writing data to the log. Given the nature of logging, chances are pretty good that your flushing that output as soon as you write it (to ensure it isn't lost). Writing to disk is (again) quite a slow operation -- you need a fairly fast enterprise-class SSD to even get into the range of tens of thousands of IOPs/second. A disk used for logging might easily be limited to something like hundreds of IOPs/second.

Bottom line: there are cases where exception handling overhead can be significant, but this almost certainly is not one of them.