This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

Inner Exceptions

As you may suspect, it is entirely possible to trigger an exception at the time you are handling

another exception. For example, assume that you are handling a CarIsDeadException within a par-

ticular catch scope, and during the process you attempt to record the stack trace to a file on your

C drive named carErrors.txt (you must specify you are using the System.IO namespace to gain

access to these I/O-centric types):

catch(CarIsDeadException e)

{

// Attempt to open a file named carErrors.txt on the C drive.

FileStream fs = File.Open(@"C:\carErrors.txt", FileMode.Open);

...

}

Now, if the specified file is not located on your C drive, the call to File.Open() results in a

FileNotFoundException! Later in this text, you will learn all about the System.IO namespace where

you will discover how to programmatically determine whether a file exists on the hard drive before

attempting to open the file in the first place (thereby avoiding the exception altogether). However,

to keep focused on the topic of exceptions, assume the exception has been raised.

When you encounter an exception while processing another exception, best practice states

that you should record the new exception object as an “inner exception” within a new object of the

same type as the initial exception (that was a mouthful). The reason we need to allocate a new

object of the exception being handled is that the only way to document an inner exception is via

a constructor parameter. Consider the following code:

catch (CarIsDeadException e)

{

try

{

FileStream fs = File.Open(@"C:\carErrors.txt", FileMode.Open);

...

}

catch (Exception e2)

{