Mitch Wheat - Treat the cause, not the symptoms!

As a developer, some of the books I have on hand get read and re-read (partly due to low retention!). One such book is the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina; every .NET developer should have a copy of this within arms reach! After a discussion about exception handling best practices with another developer, I went back to this book for a re-read…and coincidently the same day, Scott Hanselman had made a post about the same topic. (I’m going to post this in 4 parts rather than one large post…)

The benefits of using exception handling over error return value based reporting are:

• Exceptions promote API consistency, because they are designed for the sole purpose of error reporting. In contrast, error return codes can be easily ignored or overlooked.
• Exceptions integrate well with object-oriented languages. When you have no control over error return values (in operator overloads, for example), an out of band mechanism is required.
• With exception based error reporting, error handling code does not have to be close to the point of failure. In fact, developers have a choice of where to site the error handling code.
• Exceptions can make your production code more robust than equivalent code that ignores error return values, because more problems will be caught during testing.
• Exceptions can have rich textual error information describing the cause of the failure rather than some obscure error number.

Although you should not use return codes to indicate failures, you can still return status information for successful operations (such as returning the number of records inserted).

part 2, part 3 and part 4 are here.