Foundations of Programming - Karl Seguin

Chapter 8 - Back to Basics: Exceptions
Back to Basics: Exceptions
FAIL FAST - JIM SHORE
E
xceptions are such powerful constructs that developers can get a little overwhelmed and far too
defensive when dealing with them. This is unfortunate because exceptions actually represent a
key opportunity for developers to make their system considerably more robust. In this chapter
we'll look at three distinct aspects of exceptions : handling, creating and throwing them. Since
exceptions are unavoidable you can neither run nor hide, so you might as well leverage.
Handling Exceptions
Your strategy for handling exceptions should consist of two golden rules:
1. Only handle exceptions that you can actually do something about, and
2. You can't do anything about the vast majority of exceptions
Most new developers do the exact opposite of the first rule, and fight hopelessly against the second.
When your application does something deemed exceptionally outside of its normal operation the best
thing to do is fail it right then and there. If you don't you won't only lose vital information about your
mystery bug, but you risk placing your application in an unknown state, which can result in far worse
consequences.
Whenever you find yourself writing a try/catch statement, ask yourself if you can actually do something
about a raised exception. If your database goes down, can you actually write code to recover or are you
better off displaying a friendly error message to the user and getting a notification about the problem?
It's hard to accept at first, but sometimes it's just better to crash, log the error and move on. Even for
mission critical systems, if you're making typical use of a database, what can you do if it goes down? This
train of thought isn't limited to database issues or even just environmental failures, but also your typical
every-day runtime bug . If converting a configuration value to an integer throws a FormatException
does it make sense continuing as if everything's ok? Probably not.
Of course, if you can handle an exception you absolutely ought to - but do make sure to catch only the
type of exception you can handle. Catching exceptions and not actually handling them is called
exception swallowing (I prefer to call it wishful thinking) and it's a bad code. A common example I see
has to do with input validation. For example, let's look at how not to handle a categoryId being
passed from the QueryString of an ASP.NET page.
int categoryId;
try
{
categoryId = int.Parse(Request.QueryString["categoryId"]);
}
catch(Exception)
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
64
8