It’s a fact of life that bad things sometimes happen. Tires are punctured, batteries run down, screwdrivers are never where you left them, and users of your applications behave in an unpredictable manner. In the world of computers, hard disks become corrupt, other applications running on the same computer as your program run amok and use up all the available memory, wireless network connections disappear at the most awkward moment, and even natural phenomena such as a nearby lightning strike can have an impact if it causes a power outage or network failure. Errors can occur at almost any stage when a program runs, and many of them might not actually be the fault of your own application, so how do you detect them and attempt to recover?

Over the years, a number of mechanisms have evolved. A typical approach adopted by older systems such as UNIX involved arranging for the operating system to set a special global variable whenever a method failed. Then, after each call to a method, you checked the global variable to see whether the method succeeded. C# and most other modern object-oriented languages don’t handle errors in this manner; it’s just too painful. Instead, they use exceptions. If you want to write robust C# programs, you need to know about exceptions.

Errors can happen at any time, and using traditional techniques to manually add error-detecting code around every statement is cumbersome, time consuming, and error prone in its own right. You can also lose sight of the main flow of an application if each statement requires contorted error-handling logic to manage each possible error that can occur at every stage. Fortunately, C# makes it easy to separate the error-handling code from the code that implements the primary logic of a program by using exceptions and exception handlers. To write exception-aware programs, you need to do two things:

Here’s an example of code in a try block that attempts to convert strings that a user has typed in some text boxes on a form to integer values, call a method to calculate a value, and write the result to another text box. Converting a string to an integer requires that the string contain a valid set of digits and not some arbitrary sequence of characters. If the string contains invalid characters, the int.Parse method throws a FormatException, and execution transfers to the corresponding catch handler. When the catch handler finishes, the program continues with the first statement that follows the handler. Note that if there is no handler that corresponds to the exception, the exception is said to be unhandled (this situation will be described shortly).

try
{
    int leftHandSide = int.Parse(lhsOperand.Text);
    int rightHandSide = int.Parse(rhsOperand.Text);
    int answer = doCalculation(leftHandSide, rightHandSide);
    result.Text = answer.ToString();
}
catch (FormatException fEx)
{
    // Handle the exception
    ...
}

A catch handler employs syntax similar to that used by a method parameter to specify the exception to be caught. In the preceding example, when a FormatException is thrown, the fEx variable is populated with an object containing the details of the exception.

The FormatException type has a number of properties that you can examine to determine the exact cause of the exception. Many of these properties are common to all exceptions. For example, the Message property contains a text description of the error that caused the exception. You can use this information when handling the exception, perhaps recording the details to a log file or displaying a meaningful message to the user and then asking the user to try again.

Unhandled Exceptions

What happens if a try block throws an exception and there is no corresponding catch handler? In the previous example, it is possible that the lhsOperand text box contains the string representation of a valid integer but the integer it represents is outside the range of valid integers supported by C# (for example, “2147483648”). In this case, the int.Parse statement throws an OverflowException, which will not be caught by the FormatException catch handler. If this occurs and the try block is part of a method, the method immediately exits and execution returns to the calling method. If the calling method uses a try block, the runtime attempts to locate a matching catch handler for this try block and execute it. If the calling method does not use a try block or there is no matching catch handler, the calling method immediately exits and execution returns to its caller, where the process is repeated. If a matching catch handler is eventually found, the handler runs and execution continues with the first statement that follows the catch handler in the catching method.

Important

Notice that after catching an exception, execution continues in the method containing the catch block that caught the exception. If the exception occurred in a method other than the one containing the catch handler, control does not return to the method that caused the exception.

If, after cascading back through the list of calling methods, the runtime is unable to find a matching catch handler, the program terminates with an unhandled exception.

You can easily examine exceptions generated by your application. If you are running the application in Microsoft Visual Studio 2013 in debug mode (that is, on the Debug menu you selected Start Debugging to run the application) and an exception occurs, a dialog box similar to the one shown in the following image appears and the application pauses, helping you to determine the cause of the exception:

The application stops at the statement that caused the exception and you drop into the debugger. You can examine the values of variables, you can change the values of variables, and you can step through your code from the point at which the exception occurred by using the Debug toolbar and the various debug windows.

try
{
    int leftHandSide = int.Parse(lhsOperand.Text);
    int rightHandSide = int.Parse(rhsOperand.Text);
    int answer = doCalculation(leftHandSide, rightHandSide);
    result.Text = answer.ToString();
}
catch (FormatException fEx)
{
    //...
}
catch (OverflowException oEx)
{
    //...
}

try
{
    int leftHandSide = int.Parse(lhsOperand.Text);
    int rightHandSide = int.Parse(rhsOperand.Text);
    int answer = doCalculation(leftHandSide, rightHandSide);
    result.Text = answer.ToString();
}
catch (Exception ex) // this is a general catch handler
{
    //...
}

catch
{
    // ...
}

Chapter 2 discusses how to use binary arithmetic operators such as + and * on primitive data types such as int and double. It also instructs that the primitive data types have a fixed size. For example, a C# int is 32 bits. Because int has a fixed size, you know exactly the range of value that it can hold: it is –2147483648 to 2147483647.

The fixed size of the int type creates a problem. For example, what happens if you add 1 to an int whose value is currently 2147483647? The answer is that it depends on how the application is compiled. By default, the C# compiler generates code that allows the calculation to overflow silently and you get the wrong answer. (In fact, the calculation wraps around to the largest negative integer value, and the result generated is –2147483648.) The reason for this behavior is performance: integer arithmetic is a common operation in almost every program, and adding the overhead of overflow checking to each integer expression could lead to very poor performance. In many cases, the risk is acceptable because you know (or hope!) that your int values won’t reach their limits. If you don’t like this approach, you can turn on overflow checking.

Regardless of how you compile an application, you can use the checked and unchecked keywords to turn on and off integer arithmetic overflow checking selectively in parts of an application that you think need it. These keywords override the compiler option specified for the project.

int number = int.MaxValue;
checked
{
    int willThrow = number++;
    Console.WriteLine("this won't be reached");
}

int number = int.MaxValue;
unchecked
{
    int wontThrow = number++;
    Console.WriteLine("this will be reached");
}

Writing checked expressions

You can also use the checked and unchecked keywords to control overflow checking on integer expressions by preceding just the individual parenthesized expression with the checked or unchecked keyword, as shown in this example:

int wontThrow = unchecked(int.MaxValue + 1);
int willThrow = checked(int.MaxValue + 1);

The compound operators (such as += and –=) and the increment, ++, and decrement, ––, operators are arithmetic operators and can be controlled by using the checked and unchecked keywords. Remember, x += y; is the same as x = x + y;.

Important

You cannot use the checked and unchecked keywords to control floating-point (noninteger) arithmetic. The checked and unchecked keywords apply only to integer arithmetic using data types such as int and long. Floating-point arithmetic never throws OverflowException—not even when you divide by 0.0. (Remember from Chapter 2 that the .NET Framework has a special floating-point representation for infinity.)

In the following exercise, you will see how to perform checked arithmetic when using Visual Studio 2013.

Use checked expressions

1. Return to Visual Studio 2013.

2. On the Debug menu, click Start Debugging.

   You will now attempt to multiply two large values.

3. In the Left Operand box, type 9876543; In the Right Operand box, type 9876543; click the * Multiplication button; and then click Calculate.

   The value –1195595903 appears in the Result box on the form. This is a negative value, which cannot possibly be correct. This value is the result of a multiplication operation that silently overflowed the 32-bit limit of the int type.

4. Return to Visual Studio and stop debugging.

5. In the Code and Text Editor window displaying MainWindow.xaml.cs, locate the multiplyValues method, which should look like this:

   private void multiplyValues()
   {
       int lhs = int.Parse(lhsOperand.Text);
       int rhs = int.Parse(rhsOperand.Text);
       int outcome = 0;
       outcome = lhs * rhs;
       expression.Text = lhsOperand.Text + " * " + rhsOperand.Text;
       result.Text = outcome.ToString();;
   }

   The statement outcome = lhs * rhs; contains the multiplication operation that is silently overflowing.

6. Edit this statement so that the calculation value is checked, like this:

   outcome = checked(lhs * rhs);

   The multiplication is now checked and will throw an OverflowException rather than silently returning the wrong answer.

7. On the Debug menu, click Start Debugging.

8. In the Left Operand box, type 9876543; in the Right Operand box, type 9876543; click the * Multiplication button; and then click Calculate.

   Visual Studio drops into the debugger and reports that the multiplication resulted in an OverflowException exception. You now need to add a handler to catch this exception and handle it more gracefully than just failing with an error.

9. On the Debug menu, click Stop Debugging.

10. In the Code and Text Editor window displaying the MainWindow.xaml.cs file, locate the calculateClick method.

11. Add the following catch handler (shown in bold) immediately after the existing FormatException catch handler in this method:

    private void calculateClick(object sender, RoutedEventArgs e)
    {
        try
        {
            ...
        }
        catch (FormatException fEx)
        {
            result.Text = fEx.Message;
        }
        catch (OverflowException oEx)
        {
            result.Text = oEx.Message;
        }
    }

    The logic of this catch handler is the same as that for the FormatException catch handler. However, it is still worth keeping these handlers separate rather than simply writing a generic Exception catch handler because you might decide to handle these exceptions differently in the future.

12. On the Debug menu, click Start Debugging to build and run the application.

13. In the Left Operand box, type 9876543; in the Right Operand box, type 9876543; click the * Multiplication button; and then click Calculate.

    The second catch handler successfully catches the OverflowException and displays the message “Arithmetic operation resulted in an overflow” in the Result box.

14. Return to Visual Studio and stop debugging.

Exception handling and the Visual Studio debugger

By default, the Visual Studio Debugger only stops an application that is being debugged and reports exceptions that are unhandled. Sometimes it is useful to be able to debug exception handlers themselves, and in this case, you need to be able to trace exceptions when they are thrown by the application prior to them being caught. You can easily enable this functionality. On the Debug menu, click Exceptions. In the Exceptions dialog box, select the Thrown column for Common Language Runtime Exceptions, and then click OK:

Now, when exceptions such as OverflowException occur, Visual Studio will drop into the debugger, and you can use the Step Into button on the Debug toolbar to step into the catch handler. If you don’t want to catch all Common Language Runtime (CLR) exceptions in this way, you can be more selective. If you expand the Common Language Runtime Exceptions node, you can see the different categories of exceptions that can occur (they are organized by namespace). If you expand any namespace, you can see the individual exceptions that are available, and you can select each of them individually.

Suppose that you are implementing a method called monthName that accepts a single int argument and returns the name of the corresponding month. For example, monthName(1) returns “January”, monthName(2) returns “February”, and so on. The question is, what should the method return if the integer argument is less than 1 or greater than 12? The best answer is that the method shouldn’t return anything at all—it should throw an exception. The .NET Framework class libraries contain lots of exception classes specifically designed for situations such as this. Most of the time, you will find that one of these classes describes your exceptional condition. (If not, you can easily create your own exception class, but you need to know a bit more about the C# language before you can do that.) In this case, the existing .NET Framework ArgumentOutOfRangeException class is just right. You can throw an exception by using the throw statement, as shown in the following example:

public static string monthName(int month)
{
   switch (month)
   {
      case 1 :
          return "January";
      case 2 :
          return "February";
      ...
      case 12 :
          return "December";
      default :
          throw new ArgumentOutOfRangeException("Bad month");
   }
}

The throw statement needs an exception object to throw. This object contains the details of the exception, including any error messages. This example uses an expression that creates a new ArgumentOutOfRangeException object. The object is initialized with a string that populates its Message property by using a constructor. Constructors are covered in detail in Chapter 7.

In the following exercises, you will modify the MathsOperators project to throw an exception if the user attempts to perform a calculation without specifying an operator.

Now that you have written a throw statement and verified that it throws an exception, you will write a catch handler to handle this exception.

The application is now a lot more robust. However, several exceptions could still arise that are not caught and will cause the application to fail. For example, if you attempt to divide by 0, an unhandled DivideByZeroException will be thrown. (Integer division by 0 does throw an exception, unlike floating-point division by 0.) One way to solve this problem is to write an ever larger number of catch handlers inside the calculateClick method. Another solution is to add a general catch handler that catches Exception at the end of the list of catch handlers. This will trap all unexpected exceptions that you might have forgotten about or that might be caused as a result of truly unusual circumstances.

It is important to remember that when an exception is thrown, it changes the flow of execution through the program. This means that you can’t guarantee a statement will always run when the previous statement finishes because the previous statement might throw an exception. Remember that in this case, after the catch handler has run, the flow of control resumes at the next statement in the block holding this handler and not at the statement immediately following the code that raised the exception.

Look at the example that follows, which is adapted from the code in Chapter 5. It’s very easy to assume that the call to reader.Dispose will always occur when the while loop completes (if you are using Windows 7 or Windows 8, you can replace reader.Dispose with reader.Close in this example). After all, it’s right there in the code.

TextReader reader = ...;
...
string line = reader.ReadLine();
while (line != null)
{
    ...
    line = reader.ReadLine();
}
reader.Dispose();

Sometimes it’s not an issue if one particular statement does not run, but on many occasions it can be a big problem. If the statement releases a resource that was acquired in a previous statement, failing to execute this statement results in the resource being retained. This example is just such a case: when you open a file for reading, this operation acquires a resource (a file handle), and you must ensure that you call reader.Dispose to release the resource (reader.Close actually calls reader.Dispose in Windows 7 and Windows 8 to do this). If you don’t, sooner or later you’ll run out of file handles and be unable to open more files. If you find file handles are too trivial, think of database connections, instead.

The way to ensure that a statement is always run, whether or not an exception has been thrown, is to write that statement inside a finally block. A finally block occurs immediately after a try block or immediately after the last catch handler after a try block. As long as the program enters the try block associated with a finally block, the finally block will always be run, even if an exception occurs. If an exception is thrown and caught locally, the exception handler executes first, followed by the finally block. If the exception is not caught locally (that is, the runtime has to search through the list of calling methods to find a handler), the finally block runs first. In any case, the finally block always executes.

The solution to the reader.Close problem is as follows:

TextReader reader = ...;
...
try
{
    string line = reader.ReadLine();
    while (line != null)
    {
        ...
        line = reader.ReadLine();
    }
}
finally
{
    if (reader != null)
    {
        reader.Dispose();
    }
}

Even if an exception occurs while reading the file, the finally block ensures that the reader.Dispose statement always executes. You’ll see another way to handle this situation in Chapter 14.

In this chapter, you learned how to catch and handle exceptions by using the try and catch constructs. You saw how to turn on and off integer overflow checking by using the checked and unchecked keywords. You learned how to throw an exception if your code detects an exceptional situation, and you saw how to use a finally block to ensure that critical code always runs, even if an exception occurs.