To signal an abnormal condition in a C# class, you throw an exception. To do this, use the keyword throw. This line of code creates a new instance of System.Exception and then throws it:

throw new System.Exception(  );

Throwing an exception immediately halts execution of the current “thread” (see Chapter 21 for a discussion of threads) while the CLR searches for an exception handler. If an exception handler can’t be found in the current method, the runtime unwinds the stack, popping up through the calling methods until a handler is found. If the runtime returns all the way through Main( ) without finding a handler, it terminates the program. Example 11-1 illustrates.

using System;

namespace Programming_CSharp
{
    public class Test
    {
        public static void Main(  )
        {
            Console.WriteLine("Enter Main...");
            Test t = new Test(  );
            t.Func1(  );
            Console.WriteLine("Exit Main...");
        }

        public void Func1(  )
        {
            Console.WriteLine("Enter Func1...");
            Func2(  );
            Console.WriteLine("Exit Func1...");
        }

        public void Func2(  )
        {
            Console.WriteLine("Enter Func2...");
            throw new System.ApplicationException(  );
            Console.WriteLine("Exit Func2...");
        }
    }
}


Output:
Enter Main...
Enter Func1...
Enter Func2...

When you run this program in debug mode, an “Exception was unhandled” message box comes up, as shown in Figure 11-1.

Figure 11-1. Unhandled exception

If you click View Detail, you find the details of the unhandled exception, as shown in Figure 11-2.

Figure 11-2. Exception details

This simple example writes to the console as it enters and exits each method. Main( ) creates an instance of type Test and call Func1( ). After printing out the Enter Func1 message, Func1( ) immediately calls Func2( ). Func2( ) prints out the first message and throws an object of type System.Exception.

Execution immediately shifts to handling the exceptions. The CLR looks to see whether there is a handler in Func2( ). There is not, and so the runtime unwinds the stack (never printing the exit statement) to Func1( ). Again, there is no handler, and the runtime unwinds the stack back to Main( ). With no exception handler there, the default handler is called, which opens the exception message box.

In C#, an exception handler is called a catch block and is created with the catch keyword.

In Example 11-2, the throw statement is executed within a try block, and a catch block is used to announce that the error has been handled.

using System;
using System.Collections.Generic;
using System.Text;

namespace CatchingAnException
{
    public class Test
    {
        public static void Main(  )
        {
            Console.WriteLine("Enter Main...");
            Test t = new Test(  );
            t.Func1(  );
            Console.WriteLine("Exit Main...");
        }

        public void Func1(  )
        {
            Console.WriteLine("Enter Func1...");
            Func2(  );
            Console.WriteLine("Exit Func1...");
        }

        public void Func2(  )
        {
            Console.WriteLine("Enter Func2...");try
                {
                Console.WriteLine("Entering try block...");
                throw new System.ApplicationException(  );
                Console.WriteLine("Exiting try block...");
            }
            catch
            {
                // simplified for this book; typically you would
                // correct (or at least log) the problem
                Console.WriteLine("Exception caught and handled.");
            }

            Console.WriteLine("Exit Func2...");
        }
    }
}


Output:
Enter Main...
Enter Func1...
Enter Func2...
Entering try block...
Exception caught and handled.
Exit Func2...
Exit Func1...
Exit Main...

Example 11-2 is identical to Example 11-1 except that now the program includes a try/catch block.

It is a common mistake to clutter your code with try/catch blocks that don’t actually do anything and don’t solve the problem that the exception is pointing out. It is good programming practice to use a try/catch block only where your catch has the opportunity to rectify the situation (with the exception of the topmost level where, at a minimum, you want to fail reasonably gracefully).

An exception to this practice is to catch and log the exception, and then rethrow it for it to be handled at a higher level, or to catch the exception, add context information, and then nest that information bundled inside a new exception, as described later in this chapter.

Catch statements can be generic, as shown in the previous example, or can be targeted at specific exceptions, as shown later in this chapter.

using System;

namespace CatchingExceptionInCallingFunc
{
    public class Test
    {
        public static void Main(  )
        {
            Console.WriteLine("Enter Main...");
            Test t = new Test(  );
            t.Func1(  );
            Console.WriteLine("Exit Main...");
        }

        public void Func1(  )
        {
            Console.WriteLine("Enter Func1...");try
            {
                Console.WriteLine("Entering try block...");
                Func2(  );
                Console.WriteLine("Exiting try block...");
            }
            catch
            {
                Console.WriteLine(
                    "Unknown exception caught when calling Func 2.");
            }

            Console.WriteLine("Exit Func1...");
        }

        public void Func2(  )
        {
            Console.WriteLine("Enter Func2...");
            throw new System.ApplicationException(  );
            Console.WriteLine("Exit Func2...");
        }
    }
}



Output:
Enter Main...
Enter Func1...
Entering try block...
Enter Func2...
Unknown exception caught when calling Func 2.
Exit Func1...
Exit Main...

So far, you’ve been working only with generic catch statements. Best practices, however, dictate that you want, whenever possible, to create dedicated catch statements that will handle only some exceptions and not others, based on the type of exception thrown. Example 11-4 illustrates how to specify which exception you’d like to handle.

using System;

namespace SpecifyingCaughtException
{
    public class Test
    {
        public static void Main(  )
        {
            Test t = new Test(  );
            t.TestFunc(  );
        }

        // try to divide two numbers
        // handle possible exceptions
        public void TestFunc(  )
        {
            try
            {
                double a = 5;double b = 0;
                //double b = 2;
                Console.WriteLine("{0} / {1} = {2}",
                a, b, DoDivide(a, b));
            }

            // most derived exception type first
            catch (System.DivideByZeroException)
            {
                Console.WriteLine(
                "DivideByZeroException caught!");
            }
            catch (System.ArithmeticException)
            {
                Console.WriteLine(
                "ArithmeticException caught!);
            }

            // generic exception type last
            Catch (Exception e)
            {
                Console.Writeline("Log: " + e.ToString(  ));
            }
        }   // end Test function

        // do the division if legal
        public double DoDivide(double a, double  b)
        {
            if (b == 0)
                throw new System.DivideByZeroException(  );
            if (a == 0)
                throw new System.ArithmeticException(  );
            // throw new ApplicationException(  );
            return a / b;
        }
    }  // end class
}      // end namespace


Output:
DivideByZeroException caught!

In this example, the DoDivide( ) method doesn’t let you divide 0 by another number, nor does it let you divide a number by 0. It throws an instance of DivideByZeroException if you try to divide by 0. If you try to divide 0 by another number, there is no appropriate exception; dividing 0 by another number is a legal mathematical operation, and shouldn’t throw an exception at all. For the sake of this example, assume you don’t want 0 to be divided by any number and throw an ArithmeticException.

When the exception is thrown, the runtime examines each exception handler in order and matches the first one it can. When you run this with a=5 and b=7, the output is:

5 / 7 = 0.7142857142857143

As you’d expect, no exception is thrown. However, when you change the value of a to 0, the output is:

ArithmeticException caught!

The exception is thrown, and the runtime examines the first exception, DivideByZeroException. Because this doesn’t match, it goes on to the next handler, ArithmeticException, which does match.

In a final pass through, suppose you change a to 7 and b to 0. This throws the DivideByZeroException.

When catching the generic exception, it is often a good idea to at least log as much about the exception as possible by calling ToString on the exception. To see this at work, make three changes to the previous example:

The output will look something like this:

Log this: System.SystemException: System error.
   atSpecifyingCaughtException.Test.DoDivide(Double a, Double b) in C:/.../
Specified Exception
s/Program.cs:line 53

Notice that among other things, the generic exception tells you the file, the method, and the line number; this can save quite a bit of debugging time.

In some instances, throwing an exception and unwinding the stack can create a problem. For example, if you have opened a file or otherwise committed a resource, you might need an opportunity to close the file or flush the buffer.

If there is some action you must take regardless of whether an exception is thrown (such as closing a file), you have two strategies to choose from. One approach is to enclose the dangerous action in a try block, and then to close the file in both the catch and try blocks. However, this is an ugly duplication of code, and it’s error-prone. C# provides a better alternative in the finally block.

The code in the finally block is guaranteed to be executed regardless of whether an exception is thrown. The TestFunc( ) method in Example 11-5 simulates opening a file as its first action. The method undertakes some mathematical operations, and the file is closed. It is possible that some time between opening and closing the file an exception will be thrown.

If this were to occur, it would be possible for the file to remain open. The developer knows that no matter what happens, at the end of this method the file should be closed, so the file close function call is moved to a finally block, where it will be executed regardless of whether an exception is thrown.

using System;
using System.Collections.Generic;
using System.Text;

namespace UsingFinally
{
    public class Test
    {
        public static void Main(  )
        {
            Test t = new Test(  );
            t.TestFunc(  );
        }

        // try to divide two numbers
        // handle possible exceptions
        public void TestFunc(  )
        {
            try
            {
                Console.WriteLine("Open file here");
                double a = 5;
                double b = 0;
                Console.WriteLine("{0} / {1} = {2}",
                a, b, DoDivide(a, b));
                Console.WriteLine(
                "This line may or may not print");
            }

            // most derived exception type first
            catch (System.DivideByZeroException)
            {
                Console.WriteLine(
                "DivideByZeroException caught!");
            }
            catch
            {
                Console.WriteLine("Unknown exception caught");
            }finally
            {
                Console.WriteLine("Close file here.");
            }
        }

        // do the division if legal
        public double DoDivide(double a, double b)
        {
            if (b == 0)
                throw new System.DivideByZeroException(  );
            if (a == 0)
                throw new System.ArithmeticException(  );
            return a / b;
        }
    }
}


Output:
Open file here
DivideByZeroException caught!
Close file here.

Output when b = 12:
Open file here
5 / 12 = 0.416666666666667
This line may or may not print
Close file here.

In this example, one of the catch blocks is eliminated to save space, and a finally block is added. Whether or not an exception is thrown, the finally block is executed (in both output examples you see the message Close file here.).