Errors and Exceptions Series: Part 1

Data Education founder Adam Machanic will be posting a new series of blog posts on errors and exceptions in Microsoft SQL Server. The posts will cover everything from the TRY/CATCH syntax to the delicate relationship between transactions and exceptions. In this first post, Adam begins with a basic explanation of the difference between errors and exceptions, a differentiation that is sometimes glossed over by developers.

As software developers, we often daydream of a perfect world of bug-free software, developed on a remote island far from the stressors of a floundering economy, while sitting under a palm tree sipping a fruity beverage. But alas, this is 2011, and the closest thing to a palm tree is the ficus plant in the corner of the cubicle farm, where we hoards of real developers are instead sipping Keurig-brewed coffee and fighting real-world bugs that are not always our fault or under our control in any way.

Exceptions can occur in even the most stringently tested software, simply because not every condition can be checked for in advance. For instance, do you know what will happen if a janitor, while cleaning the data-center floor, accidentally slops some mop water into the fan enclosure of the database server? It might crash… or it might not. Or it might just cause some component to fail somewhere deep in the app, sending up a strange error message.

Although most exceptions happily won’t be so far out of the realm of testability, it is certainly important to understand how to deal with them when and if they occur. It is also imperative that SQL Server developers understand how to work with errors—both those thrown by the server itself and custom errors built specifically for when problems occur during the run time of an application.

Exceptions vs. Errors

The terms exception and error, while often used interchangeably by developers, actually refer to slightly different conditions. An error can occur if something goes wrong during the course of a program, or it can be purely informational in nature. For instance, a program telling a user that a question mark is an invalid character for a filename is considered to be an error message. However, this may or may not mean that the program itself is in an invalid state.

An exception is an error that is the result of an exceptional circumstance. For example, if a network library is being used to send packets and the network connection is suddenly dropped due to someone unplugging a cable, the library might throw an exception. An exception tells a caller that something went wrong and the routine aborted unexpectedly. If the caller does not handle the exception (i.e., capture it), its execution will also abort. This process will keep repeating until the exception is handled, or until it reaches the highest level of the call stack, at which point the entire program will fail.

Another way to think about exceptions and errors is to think of general errors as expected by the program. The error message that occurs when a filename contains an invalid character is informational in nature because the developer of the program predicted that such an occurrence would be common and created a code path to specifically deal with it. Yet a dropped network connection could be caused by any number of circumstances and therefore is much more difficult to handle specifically; therefore, the solution will be to raise an exception and fail. The exception can then be handled by a routine higher in the call stack, which can decide what course of action to take in order to solve the problem.

There is some debate in the software community on whether exceptions should really be used for only exceptional circumstances. In my opinion, due to the fact that exceptions can cause abort conditions, they should be used sparingly. However, this is not always the pattern seen in commercial libraries. For example, Microsoft’s .NET Framework uses an InvalidOperationException to tell the caller that an instance of Queue<T> is empty if the caller tries to use the Dequeue method. Personally, I find this to be a blatant misuse of exceptions. That said, there is certainly an upside to using exceptions over errors, which is that it’s more difficult for the caller to ignore an exception, since it will cause code to abort if not properly handled. If you’re designing an interface that needs to absolutely ensure that the caller sees a certain condition if and when it occurs? Well, then it might make sense to use an exception rather than an error.

Later this week, watch for Part 2 of the Errors and Exceptions Series: How Exceptions Actually Work in SQL Server.