LeeDumond.com

What can driving a car teach us about exception handling? Apparently, quite a lot.

---

If you drive a car, you probably have automobile insurance. But even though you may be covered by insurance, an accident can still be pretty expensive, financially and otherwise. You would probably agree that no matter how much insurance you may have in place, it’s smart to be a “defensive driver” and avoid getting into an accident in the first place.

Exceptions are like accidents, and exception handling is like car insurance. While it’s vitally important to have, and though it may get you “back on the road,” exception handling is really no substitute for good defensive programming. Exceptions are “expensive” in terms of the resources and additional overhead they incur. Because of this, you should anticipate when, where, and how exceptions could be thrown, and do your best to “steer” your code around them.

Always Validate Input

Input validation is like buckling your seat belt - it's the very first thing you should think about before working with any kind of user input.  Validation is the most important measure you can take to ensure that your application doesn’t have to deal with bad input in the first place.

Consider the following LogEntry method, which takes an entry supplied by a user and writes that entry into a text file:

protected void LogEntry(object sender, EventArgs e)
{
   string path = GetPathToLog();
   StreamWriter writer = File.AppendText(path);
   writer.WriteLine(DateTime.Now.ToString(CultureInfo.InstalledUICulture));
   writer.WriteLine("Entry: {0}", txtLogEntry.Text);
   writer.WriteLine("--------------------");
   writer.Dispose();
}

This method has a call to File.AppendText (which takes as an argument a string indicating the physical path to the file you want to append to), as well as several calls to the StreamWriter.WriteLine method. Now, stop for a moment and think about all the things that could go wrong here.

• path could be an empty string.
• path could be null.
• path could be too long.
• path could contain invalid characters.
• path could be in an invalid format.
• path could point to a file outside the web site.
• path could point to a valid directory, but not a specific file.
• The directory specified in path may not exist.
• The file specified in path may not exist.
• The file may be read-only.
• The ASP.NET account may not have sufficient permissions on the directory.
• The file may be locked by a previous process.
• There could be a disk error while opening the file or writing to the disk.
• Something could go wrong outside of the file I/O system — the computer’s memory could suddenly become corrupted, for example.

If any of the above scenarios actually does take place, a runtime error will occur, and the CLR will throw an exception.

Now assume that the GetPathToLog method (line 3 in the above code) relies on the user to enter a path into a textbox on a web page. By adding some validation to that textbox, you can eliminate some of the exception cases you have to deal with, as shown below:

You can see that by using a RequiredFieldValidator, you ensure that path can never be null or empty. By using a  RegularExpressionValidator, you ensure that the path cannot contain invalid characters or be in an invalid format. And by setting the MaxLength property on the textbox, you ensure that the path cannot be too long. Because these validations have eliminated the possibility of some exceptions being thrown, you don’t need to worry about handling them.

Validate or restrict user input to reduce the likelihood of exceptions being thrown.

Check for Error Conditions

Much like automobile insurance, exception handling only kicks in after something bad has already occurred. However, you often have the option of programmatically determining if an error condition could potentially occur before it actually does.

The option you choose — exception handling or programmatically checking for error conditions — depends on whether the condition is truly exceptional (a state that occurs infrequently or unexpectedly) or non-exceptional (a normal and predictable condition).

• If the condition can be considered exceptional, then using exception handling is more efficient because fewer lines of code are executed under normal conditions.
• If the condition is non-exceptional, then programmatic checking is more efficient because fewer exceptions will be thrown.

This is best illustrated by an example. Let’s say that you have a blog application in which you allow users to rate blog posts from 1 to 5. Let’s also say that you want to display the average rating for each post. If you store the total rating a post has received, along with the number of times it has been rated, you can calculate the average rating as shown below:

public double AverageRating
{
   get { return (double) TotalRating / NumOfVotes; }
}

This works great — as long as the article has been rated by at least one person. But what if the article has never been rated? In the code above, if NumOfVotes is 0, the getter will fail with a DivideByZeroException.

Now, let’s see what we can do to fix this:

public double AverageRating
{
   get
   {
      try
      {
         return (double) TotalRating / NumOfVotes;
      }
      catch (DivideByZeroException)
      {
         return 0.0;
      }
   }
}

Well, this takes care of the case in which the article has never been rated, and that’s what we wanted to do. However, this solution is less than ideal because it allows an exception to be thrown in what really can’t be considered an exceptional circumstance. That a post has not yet been rated is a totally normal and predictable state of affairs. Relying on an exception to handle normal cases like this is like parking your car on the train tracks — it’s only a matter of time before the inevitable happens.

Now, consider this option instead:

public double AverageRating
{
   get
   {
      if (NumOfVotes == 0)
      {
         return 0.0;
      }
      else
      {
         return (double) TotalRating / NumOfVotes;
      }
   }
}

The code above presents a much better solution, because it takes unrated posts into account without relying on an exception to do so.

The example I’ve just presented shows how to avoid having to handle a DivideByZeroException by testing a divisor’s value before performing division arithmetic. There are several other defensive programming strategies you can use to avoid many commonly thrown CLR exceptions.

Defensive Programming Strategies

• Check for Nulls — Trying to use a null object in code will result in a NullReferenceException. If there is any possibility an object could be null, check for that before calling its methods or accessing its properties.
   
• Check Object State — The current state of an object may prevent certain methods from being called on it. For example, attempting to call the Close method on a connection that is already closed will throw an InvalidOperationException. Check the state of an object before performing operations that require a specific state.
   
• Check Your Arguments — Many methods and constructors require arguments to be non-null, in a certain format, or within a range of acceptable values. For example, attempting to create a DateTime of February 30, 2009 will result in an ArgumentOutOfRangeException, because February doesn’t have 30 days. Make sure that the arguments you pass conform to the expectations of the method you are invoking.
   
• Be Careful When Working with Arrays — Remember that the elements of an array are of a certain type and that arrays are always of a fixed length. Attempting to store an element of the wrong type in an array throws an ArrayTypeMismatchException. Attempting to access an element with an index less than zero or greater than the size of the array throws an IndexOutOfRangeException. Try to determine if these conditions could occur, and write your code accordingly.
   
• Establish Bounds for Iterations and Recursions — While recursive methods (methods that call themselves during execution) are sometimes very handy, you need to guard against the possibility of infinite recursion — lest your execution fall into an endless loop, resulting in a nasty StackOverFlowException. The StackOverFlowException is unique in the .NET Framework because, unlike most other exceptions, it cannot be caught in a try-catch construct. Therefore, this is one of those rare situations in which programmatic handling is your only choice. Make sure that you don’t accidentally code an endless loop by failing to define a condition that, when met, will cause the recursion to end.
   
• Use Safe Casting — If you attempt to cast an object to a type with which it is not compatible, an InvalidCastException will result. This usually happens when the type of the object you are casting is not known at design time. In these cases, you can use the as or is operators to prevent the exception. The as operator first checks if the cast can be performed successfully, and if so, returns the result of the cast; otherwise, null is returned. The is operator only returns true if the cast would succeed, and false otherwise, without actually casting the object.
   
• Use Safe Parsing — In .NET, value types expose Parse and TryParse methods, both of which convert a string representation of a value to an actual value of the type. The difference between the two is that Parse throws a FormatException if the string cannot be converted, while TryParse only returns a Boolean value — true if the conversion succeeds, and false if it does not — while returning the actual parsed value as an out parameter. When performing parsing operations you suspect may fail, you can use TryParse to prevent an exception from being thrown.

Keep in mind that programmatic checking doesn’t make sense in all cases. For example, you might think that checking the value of File.Exists before calling File.Open is a good idea, but a race condition exists in which the file may be deleted in the split second that elapses between the two method calls. Therefore, in this case, you should handle the FileNotFoundException, by prompting the user for a different filename or by creating the file.

Programmatically check for ordinary cases that might cause an error condition. Allow exceptions to be thrown only in exceptional cases, or when a race condition makes checking impractical.

This is by no means an exhaustive list of defensive programming techniques, but you get the idea.

Summary

1. Validate or restrict user input to reduce the likelihood of exceptions being thrown. 
2. Devise defensive programming strategies to prevent your code from causing exceptions to be thrown when appropriate. 
3. In cases where truly exceptional circumstances may occur, or where programmatic error checking is impractical, be prepared to handle the resulting exception as needed.

Following these few simple rules probably won't do much to keep your car insurance rates down, but they'll definitely keep your code running a whole lot smoother!

Subscribe to this blog for more cool content like this!

Bookmark / Share