Why Exceptions Suck

Wrong. Exceptions, unlike GOTOs, can't jump straight into a loop or any construct that has a local state. In fact, exceptions never break local states, and that's their beauty.

The best proof that exceptions don't break anything is that you can always represent a throw/catch cycle with IF's, RETURN's, possibly also subroutines, but there will be no GOTOs. You will have equivalent functionality, except the code will be a bit bloated and less readable.

I'm not sure I buy that.

Why do people keep parroting this?

It's much harder to use a return code badly

Return codes are almost always ignored. In straight C, errors are a real pain. They just are. In working code, the evils of exceptions don't come up, because you don't get exceptions for the most part. As a practical matter, they're just debugging tools, and not control handlers.

When you read Ruby code you have no idea if the programmer thought about exceptions at all. In order to figure out what exceptions should be possibly handled you have to take the union of all the exceptions that can be thrown by all the functions you call, and then check if they are all handled correctly. Unfortunately, it's impossible to determine which exceptions can be thrown by a function, because any function can throw any number of exceptions. If your buddy decides to throw a new exception in some helper function then the exception signature of a hundred functions changes.

So basically, there's no way of telling whether the code is correct. Good luck with that. So people give up and just rescue every possible error and return a default value, excactly like described in the article.

For your enjoyment:

http://www.google.com/codesearch?q=lang%3Aruby+rescue&hl...

And this is production code you're looking at.

I don't want to get into the details here, but Kent Pitman wrote a great paper on the subject: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...

   try {
      connect_to_database;
      prepare_query("SELECT * FROM ...");
      run_query;
      return results;
   }
   catch database error {
      warn "Whoa, your database is broken!";
   }

   dbh = connect_to_database;
   if(!dbh){
      errno = 0x23843;
      return NULL;
   }
   statement = prepare_query;
   if(!statement){
      errno = 0x28783;
      return NULL;
   }

I don't think exceptions suck. Errors are what suck.

Exceptions usually suck because people are trying to graft some kind of complicated event handling system on it, to which it's not suited. Frankly, this sort of thing is better handled by co-routines. Exceptions suck because they're the often the only way to do something without more explicit control flow.

On top of this, we're supposed to be able to check everything and write error checked code, but suppressing errors can be surprisingly beneficial: observe, say, DRYing out deep checks http://code.causes.com/blog/drying-out-deep-checks.

One of the reasons GOTO sucked so much was because at the time it was all we had. Now it isn't. Explicit control flow is useful and important for certain tasks (like network programming).

Exceptions are intended for unexpected conditions (i.e., exceptional) that must be handled somehow. In C++, this is pretty fundamental to the RAII idea.

However, I don't think that going back to checking return codes solves anything. Most of the problems I see at work are related more to checked exceptions than using exceptions in general. Thankfully, most of java frameworks I use have moved towards making everything an unchecked exception.

I recently came across something like this, which struck me as a horrendous abuse of "exception" handling:

  // drastically simplified so as to not make anyone nauseous/crazy:

  try {
    $x = doSomething();
    doSomethingElse($x);
    if (!$x->foo) {
      $x->foo = "bar";
      throw new NoFooException($x);
    }
    doSomeMoreThings($x);
  } catch NoFooException {
    handleNoFooCase($x);
  }

  do {
    ...bunch of code.
    if (!$x) {
      break;
    }
    bunch more code.
    if (!$y) {
      break;
    }
    bunch more code.
  } while(false);

Frankly, GOTOs would have been easier to follow.

The answer is yes.

The thing that really bothered me is that I got the distinct feeling that the author is only parroting old advice, without actually trying anything himself.

In particular, he said that exceptions are expensive in any language. In Python in particular, exceptions are no more expensive than any other control structure, as that was an explicit design decision.

Exceptions work, that's all there is to it, but they have to be documented. The Python documentation is a very good example of this. For the built-ins in particular, every single operation states what type of exception is thrown in what case.

Exceptions can be very effective if:

1. Each function/method documents what exceptions it throws under what circumstances.

2. Exception causes are thoughtfully separated into different types. One example of a violation of this principle that has frustrated me recently is Python's os.makedirs function, which recursively creates a hierarchy of directories. This can cause an exception if one of the directories cannot be created for some reason (permissions, desired directory is an existing file, etc.) or if the leaf directory already exists. In some cases, the latter case really is not an error (you just want "mkdir -p" functionality), but it's hard to distinguish between the two cases.

3. The proper exceptions are caught. Too often programmers attempt to catch every exception and re-propagate it (or worse, ignore it). In many cases, exceptions are only meaningful during debugging, and once minor issues are worked out, the exceptional case is guaranteed to never occur. These types should be allowed to propagate to the top-level and crash the program, that is the whole point of the exception. In other cases, the programmer needs to be aware of what exceptions may occur (see 1), to reason about how such cases should be handled (if at all, perhaps allowing it to pass up the stack makes sense), and to handle it appropriately. Only in a top-level logger for a long-running program should a catch-all exception ever be used.

...and that turned out much longer than I initially planned. I am just tired of hearing the same old "exceptions are bad because people will use them to mask real errors" argument repeated over-and-over, when no programmer worth anything would ever do that. Also, this popular comparison of exceptions to GOTOs is ridiculous. The article on GOTOs was written at a time when spaghetti code which jumped all over the place to save repetition was not at all uncommon. Thanks to more recent constructs like do...while, break, continue, for loops, function objects, and more, crazy "old school" code patterns are much less common. To march that argument out today any time someone dislikes a given control flow structure is a disservice to the original paper (which was actually addressing real problems in code structure), because the comparison invariably is between apples and oranges.

I'm not even sure I understand how GOTO is unmitigated evil. Occasionally it can be the clearest way to break out of a nested loop. Doesn't the Evil GOTO song and dance come from an ancient era when it played a completely different role in languages?

This is mostly a complaint about shitty developers than about exceptions.