The world of software development has more than its fair share of topics where people tend to have long religious discussions about the “correct” way to do something. I think this is partly because the field for some reason attracts the kind of person who enjoys a nice bout of verbal fisticuffs, and partly because we spend a lot of time dealing with very abstract topics where the pros and cons of a given choice have more to do with differing philosophies than with objective facts.

One classic topic for this kind of discussion, which came up recently at work, is the use of exceptions for error handling. Every modern programming language offers an exception mechanism for this purpose, and presumably it is there to be used. However, ever since they were first introduced, there has been a large and vocal subset of the community arguing that exceptions do more harm than good and you’ll be writing better code if you just use good old return values to report whether a method succeeded.

One representative example comes from Joel Spolsky, one of my favorite authors. Another oft-quoted article making the same arguments is found in the “Frequently Questioned Answers” by Yossi Kreinin. They both make the same basic points: exceptions do not reduce complexity but merely hide it, and when complexity is hidden people tend to forget about it.

These arguments have merit, but I still feel that (when properly used) exception handling delivers enough value to be worth the cost. So I am going to be arguing for the status quo here, for a change. Executive summary: the dangers of exceptions are real, but code readability trumps almost everything.
Read the rest of this entry »