A fundamental skill in the .NET Framework is facility with structured exception handling. Yet, as essential as that skill is, the topic is given cursory attention to those new to Object Oriented Programming in general and .NET programming in particular.

Unlike our brethren in the Java world, many of us coming into .NET from Classic ASP and VB6 didn't know what a exception was until we saw the dreaded ASP.NET yellow error page that's displayed when buggy ASP.NET code is run.

As a result, the purpose of the article is provide you with a clear, working understanding of programming .NET using exceptions. Microsoft provides ample documentation about the syntax of structured exception handling, the Exception object and its derivatives. The intent of the article is not to rehash existing work. Rather, the goal here is to give you a solid conceptual understanding of whats's and why's of .NET exceptions, along with providing set of guidelines that you can follow as you incorporate structured exception handling in to your programming toolkit.

Why Return True when you can Throw?

Let's take a fast look at what an exception is, and why you would use one.

In the old days of procedural programming, you needed a way to know if a function that you were executing worked. And if it didn't work, you needed to know why. For example, let say that you have a method that makes a credit card payment as shown in Listing 1:

Listing 1: The signature of a simple credit card payment function

MakeCreditCardPayment(string FirstName, string LastName,
   string CreditCardNumber, DateTime ExpirationDate, double Amount)
{
     //some execution code goes here....
}

This function is not well designed. At the very least, you would want to know if the method worked, and that the transaction was successful. Thus, you could construct your method to return a boolean value to indicate success or failure, as shown in Listing 2.

Listing 2: A credit card payment method that returns true upon success

MakeCreditCardPayment(string FirstName, string LastName,
  string CreditCardNumber, DateTime ExpirationDate, double Amount)
{
     //some execution code goes here....
     //return true if the function works
     //or
     //return false if there is an error
}

Figure 1: Old style error handling had short many shortcomings.

However, sometimes knowing a method's success or failure is not enough information. You might want to know the reason why the method failed. In the old days, we'd return numeric values that acted as an indicator of error type, as shown below in Listing 3:

Listing 3: A method that returns error codes

MakeCreditCardPayment(string FirstName, 
  string LastName, string CreditCardNumber, 
  DateTime ExpirationDate, double Amount)
{
/      /some execution code goes here....

     //return -1 if the function works
     //or
     //return 0 as an undefined failure
     //return 1, if the credit card number is invalid
     //return 2, if the expiration date is invalid
     //return 3, if the credit limit has been exceeded.
}

This type of solution for error detection works, but it has shortcomings. You have to know how the error numbers associate to a particular error in order to work with the method in any meaningful way. The error codes are not what we call "self describing." Also, there is no easy way to "pass error information around" if you want other parts of the program to know that an error occurred.

Another important weakness in this design is that the caller is not forced to deal with the error. This is problematic in the case where the error indicates that the code is in an inconsistent state. The application could end up making important decisions based on invalid data. In this situation, it would be better for the application to shut down than to continue.