Phil’s 10 Rules for the treatment of Exceptions

You know what I love, Exceptions. Exceptions are awesome.

They’re an awesome tool that simplify post-mortem debugging, help developers code against and understand the internal workings of an API and they help prevent applications getting into a corrupt state.

Even though exceptions are so invaluable, a lot of the time they’re poorly understood, abused, ignored and forgotten. I hope that I can earn some respect for the venerable exception, by setting down some rules on how they should be treated.

Phil’s 10 rules for the treatment of Exceptions:

1. Throw early, throw often^[1]
   This is key tenet of exceptions. You must throw as early as possible. For example, if your method requires a parameter isn’t null, throw an ArgumentNullException as soon as possible, on one of the first lines in the method. An early ArgumentNullException provides much more information than a NullReferenceException later in the code, and an early exception prevents the class getting into a corrupt state.
2. Prevention is the best medicine
   You should always avoid calling methods that you know will throw an exception only to catch the exception and continue executing. It makes for hard to read code and exceptions have a performance cost, so avoid the exception being thrown in the first place if possible. For example, rather than letting a statement throw a DivideByZeroException, use an ‘if’ statement to check the divisor isn’t zero!
3. Log each, and every exception (almost)
   Once an application is in Production, or QA, the chances are you’re not going to have a debugger attached so you can see exceptions when they happen, and you’re going to have to rely on post-mortem debugging. This is why you must log everything. All exceptions that aren’t caught must be logged, and 90% of exceptions that are caught should be logged too.
4. Don’t abuse the BCL exceptions
   Knowing the type of an exception being thrown provides a lot of valuable information, so if the type is a generic base type, debugging all of a sudden becomes a lot harder. Microsoft’s guidelines recommend never throwing System.Exception, and I couldn’t agree more. That class tells you nothing about what’s gone wrong.

   Try to define your own exceptions classes when possible (ideally with the Exception snippet if you’re in C#,) give them descriptive names, meaningful properties and default messages.

5. Descriptive error messages add context
   Even if you’re throwing the right type of exception, you still need to add details to the exception to give it context, and the best way to do that is with a descriptive message. In the example of a FileNotFoundException, providing the name of the file that was missing would be a pretty good start.
6. Know that even when you’re not coding an new API, you’re coding an new API
   This is one of my core beliefs in programming, imagine that everything you write is going to be exposed as part of an API. It makes you double think what you write if you’re assuming it’s going to be of the CLR in .net 5.0! With this in mind, think about someone calling your methods, and how they’re going to be able make their own code work when yours is throwing meaningless exceptions, or worse, no exceptions at all.
7. Catch and wrap
   Catching an exception and making it the inner exception of a new exception allows you to add additional detail, giving even more context. A common networking exception might be WebException: “The underlying connection is closed.” While helpful, probably won’t give you enough info to resolve it. Catching and wrapping it in a new exception “Calling method X on remote server Y” helps tremendously.
8. Don’t use exceptions when a return value is more appropriate
   While I’d never recommend having a function return a value to indicate whether a function failed or not, I’d also never recommend throwing an exception just because there’s nothing to return. It’s okay to return null if the situation calls for it. For example, if you’re using a file for caching, and the file doesn’t exist, don’t throw a FileNotFoundException, return null since there’s nothing cached.
9. Know which exception message are and aren’t appropriate for an end user
   While it’s easy to just display the message from an exception to an end user, often they’ll have no idea what it means or how to fix it, no matter how technical they are. You should just try and cover all the common scenarios with custom UI messages, and for the edge cases, logging and ‘send crash report’ type functionality is your friend.
10. Don’t panic!
    It’s okay, exceptions aren’t a bad thing! A lot of people feel it’s necessary to catch exceptions at every chance they get. A lot of the time it’s better just to leave the exception to bubble up the stack to be handled at the topmost level, especially when the code that catches the exception then carries on as if nothing’s happened, resulting in a corrupt state and unpredictable behaviour.

For those interested in how logging is best done in ASP.NET, you might want to look at my older post.

There’s a lot to think about here, and I’m sure you all have different opinions, is there anything else you’d add to this list?

Phil

^[1]A programmer’s introduction to C# 2.0