Error Trapping

Regardless of what we developers do, most code ends up being run by users. And users do things we could never expect. And when software encounters the un-expected, exceptions occur.

To some extent our code should be prepared for some errors to occur - file does not exist, item not in list etc. The main way to handle error conditions is to use the structured error handling that is part of your development language. If your language of choice does not have structured error handling baked in (VB6/VBA for example), do some research and find a framework that can help you out because it's vital to creating solid software.

Try Catch Finally

In this section, I'm going to be using Visual Basic .NET for the examples, but the ideas are the same for any language which supports structured error handling.

Try, Catch, and Finally are three keywords in visual basic which control the main elements of exception (error) handling.

Click to View Code

In this first sample, we see the basic Try Catch block. Basically the "Try" and "Catch" statements wrap code which could throw an error. If an error occurs, it's caught at the Catch statement, where three things can occur...

  1. You can ignore it (also known as swallowing an exception)
  2. You can take corrective action - if that's possible
  3. You can throw that (or another) exception up the stack to be handles elsewhere.

Catching Specific Exceptions

In this next example, another line has been added which catches a more specific type of exception - FileNotFoundException. It's important to organize your catch blocks so that they move from the most specific to the most generic, otherwise you will not catch the more specific type. To put this another way, of the Catch ex as Exception line occured before the Catch ex as FileNotFoundException, even if a FileNotFound Exception occured, only the "Exception" block would execute.

Click to View Code

Loggin Errors

Now that your code has actually located an error, and trapped it, you need to decide what to do about it. The immediate thing is to determine if your code can continue, and if not how to exit gracefully. Once you have handled that, it may be a good idea to log the error somewhere.

One approach we have taken is to have a centralized exception handler in our application, which then can make a call to a web service and submit the exception into a bug tracker database. This has worked well for us, but writing to a text file could also work - it just depends on how how want to handle things. Another option to look at is Log4Net - which is an open source logging framework for .NET. I have not used it yet, but apparently it can be used send more comprehensive application "state" information, which can be useful when trying to determine why the exception occured.

Resources

While this introduction touches on the major points, it's not comprehensive. Here are some other resources for Error Handling.