When an error condition occurs, the programmer can generate an exception by using the throw keyword, and the exception is tagged with a piece of data that identifies exactly what has happened. At this point, normal execution stops and the exception-handling code built in to the application begins looking for a handler. It looks in the currently executing routine, and if it finds a suitable handler, the handler is executed and the application continues. If it doesn’t find a handler in the current routine, the exception-handling code moves one level up the call stack and checks for a suitable handler there. This process carries on until either the application finds a handler or it reaches the top level in the call stack—the main function. If nothing has been found by this time, the application terminates with an “unhandled exception” message.

Here’s an example of how an unhandled exception appears to you. You’ve probably seen a lot of these already! Look at the following simple code fragment:

Console::WriteLine("Exception Test");
int top = 3;
int bottom = 0;

int result = top / bottom;
Console::WriteLine("Result is {0}", result);

It’s easy to see that this code is going to cause a divide-by-zero error, and when it is executed, you see the result shown in the following screen shot:

You can see that the divide-by-zero has resulted in an exception being generated. Because I didn’t handle it in the code, the application has been terminated, and the final output never makes it to the screen. Notice the form of the standard message: it informs you as to what happened (a System::DivideByZeroException error), presents an error message, and then gives you a stack trace that directs you to where the error occurred (in this case, in the main function at line 13 in the Exception-Test.cpp file).

System::DivideByZeroException denotes the kind of object that was passed in the exception. A lot of exception classes are provided in the System namespace, and it’s also likely that you’ll make up your own based on the System::Exception base class, as you’ll see later in the chapter.

Exception handling is slightly complicated in that you might encounter three different types of exception handling when using C++/CLI: traditional C++ exceptions, C++/CLI exceptions, and Microsoft Windows Structured Exception Handling (SEH). Traditional C++ exceptions form the basis of all exception handling in C++. C++/CLI adds the ability to use managed types (for example, ref classes and value types) in exceptions, and you can mix them with traditional exceptions. C++/CLI also extends exception handling by adding the concept of a finally block, which I discuss in the section The finally block later in the chapter. The third sort of exception handling, SEH, is a form of exception handling built in to Windows operating systems that is independent from C++. I won’t talk any more about SEH here, except to note that you can interact with it from C++.

You catch exceptions and process them by using the try/catch construct, which has the following form:

try
{
    // code that may fail
}
catch(TypeOne ^one)
{
    // handle this exception
}
catch(TypeTwo ^two)
{
    // handle this exception
}

Code that you suspect might fail is enclosed in a try block that is followed by one or more handlers in the form of catch blocks. Each catch block looks a little like a function definition, with catch followed by a type in parentheses, which represents the type that will be caught and processed by the catch block. In the preceding code, the first catch block handles exceptions tagged with a TypeOne^ object, whereas the second block handles those tagged with a TypeTwo^ object.

You can chain as many catch blocks together as there are exception types to catch, as long as you have at least one.

The following exercise shows you the basics of handling exceptions, using the example from the previous exercise as a basis.

Just printing out the exception object results in the type-plus-message-plus-stack trace that you saw when the exception was unhandled. You can use properties of the Exception class to control what is printed, as shown in the following table:

Here’s a brief exercise that demonstrates the use of Exception class properties:

In a similar way, you could use StackTrace to retrieve and print the stack trace information.

The exception classes form a hierarchy based on System::Exception, and you can use this hierarchy to simplify your exception handling. As an example, consider System::ArithmeticException, which inherits from System::Exception and has subclasses that include System::DivideByZeroException and System::OverflowException. Now, look at the following code:

try
{
    // do some arithmetic operation
}
catch(System::ArithmeticException ^aex)
{
    // handle this exception
}
catch(System::DivideByZeroException ^dex)
{
    // handle this exception
}

Suppose that a DivideByZeroException is thrown. You might expect it to be caught by the second catch block, but it will, in fact, be caught by the first one. This is because according to the inheritance hierarchy, a DivideByZeroException is an ArithmeticException, so the type of the first catch block matches. To get the behavior you expect when using more than one catch block, you need to rank the catch blocks from most specific to most general.

So, if you just want to catch all arithmetic exceptions, you can simply put in a handler for ArithmeticException, and all exceptions from derived classes will be caught. In the most general case, you can simply add a handler for Exception, and all managed exceptions will be caught.

In the section What are exceptions? earlier in this chapter, I mentioned one of the advantages of exceptions is that they make it possible for you to signal an error where there’s no way to return a value. They’re very useful for reporting errors in constructors, which, as you now know, don’t have a return value.

In the following exercise, you’ll see how to define a simple class that uses an exception to report errors from its constructor, and you’ll also see how to check for exceptions when creating objects of this type.

Now that you’ve seen how to use the try/catch construct, let’s move on to cover some more advanced uses. The first of these are nesting and rethrowing exceptions.

As the name implies, nesting exceptions means including one try/catch construct within another, which can provide a useful way to handle error conditions. It works as you might expect:

try        // outer try block
{
    try      // inner try block
    {
        // Do something
    }
    catch(SomeException ^ex1)
    {
        Console::WriteLine("Exception: {0}", ex1->Message);
    }
}
catch(OtherException ^ex2)
{
    Console::WriteLine("Exception: {0}", ex2->Message);
}

If an exception occurs within the inner try block that is of type SomeException^, it will be handled by the inner catch block and execution will continue after the end of the inner catch block, as usual. The outer catch block will not be executed in this case because the error has already been adequately handled.

If an exception occurs within the inner try block that is of type OtherException^, it won’t be handled by the inner catch block, so it will be passed to the outer try and catch construct, where it is processed by the outer catch block.

Rethrowing an exception means just that—handling an exception in a catch block and then throwing it again so that it can be handled somewhere else. The following exercise shows how to catch an exception and rethrow it.

Note that you don’t have to rethrow the same exception; it’s quite usual to catch one type of exception, handle it, and then rethrow an exception of another type. You’ll see an example of this in the section Creating your own exception types later in this chapter.

C++/CLI adds a new construct to traditional C++ exception handling: the finally block. The purpose of this block is to let you clean up after an exception has occurred, and the following short exercise shows how it works.

The purpose of this block is to ensure that if you do something in the try block—such as opening a file or allocating some memory—you’ll be able to tidy up whether an exception occurs or not because the finally block is always executed when execution leaves a try block. This construct gives you a way to clean up what might otherwise require duplicate code.

Standard C++ has a construct that can be used to catch any exception that goes past. Here’s how it works:

try
{
    // do some arithmetic operation
}
catch(System::ArithmeticException ^pex)
{
    // handle this exception
}
catch(...)
{
    // handle any exception
}

If an exception doesn’t match the first catch block, it will be caught by the second one, no matter what type it is. The problem is that you lose any information about the exception, because the catch(…) block doesn’t have an argument.

If you want this functionality when using C++/CLI, use a catch block that has an Exception^ as its argument, which will catch any managed exception object.