Pro CSharp 2008 And The .NET 3.5 Platform [eng]-1
.pdf
232 CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING
■Note As a rule, all custom exception classes should be defined as public types (recall, the default access modifier of a non-nested type is internal). The reason is that exceptions are often passed outside of assembly boundaries, and should therefore be accessible to the calling code base.
Create a new Console Application project named CustomException, and copy the previous Car and Radio definitions into your new project using the Project Add Existing Item menu option (be sure to change the namespace that defines the Car and Radio types from SimpleException to CustomException). Next, add the following class definition:
// This custom exception describes the details of the car-is-dead condition. public class CarIsDeadException : ApplicationException
{}
Like any class, you are free to include any number of custom members that can be called within the catch block of the calling logic. You are also free to override any virtual members defined by your parent classes. For example, we could implement CarIsDeadException by overriding the virtual Message property.
As well, rather than filling the data collection (via the Data property) when throwing our exception, our constructor allows the sender to pass in a time stamp and reason for the error. Finally, the time stamp data and cause of the error can be obtained using strongly typed properties:
public class CarIsDeadException : ApplicationException
{
private string messageDetails; private DateTime errorTimeStamp; private string causeOfError;
public DateTime TimeStamp
{
get {return errorTimeStamp;} set {errorTimeStamp = value;}
}
public string Cause
{
get {return causeOfError;} set {causeOfError = value;}
}
public CarIsDeadException(){}
public CarIsDeadException(string message, string cause, DateTime time)
{
messageDetails = message; causeOfError = cause; errorTimeStamp = time;
}
// Override the Exception.Message property. public override string Message
{
get
{
CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING |
233 |
return string.Format("Car Error Message: {0}", messageDetails);
}
}
}
Here, the CarIsDeadException type maintains a private data member (messageDetails) that represents data regarding the current exception, which can be set using a custom constructor. Throwing this error from the Accelerate() method is straightforward. Simply allocate, configure, and throw a CarIsDeadException type rather than a System.Exception (notice that in this case, we no longer need to fill the data collection manually):
// Throw the custom CarIsDeadException. public void Accelerate(int delta)
{
...
CarIsDeadException ex =
new CarIsDeadException (string.Format("{0} has overheated!", petName), "You have a lead foot", DateTime.Now);
ex.HelpLink = "http://www.CarsRUs.com"; throw ex;
...
}
To catch this incoming exception, your catch scope can now be updated to catch a specific
CarIsDeadException type (however, given that CarIsDeadException “is-a” System.Exception, it is still permissible to catch a System.Exception as well):
static void Main(string[] args)
{
Console.WriteLine("***** Fun with Custom Exceptions *****\n");
Car myCar = new Car("Rusty", 90);
try
{
// Trip exception. myCar.Accelerate(50);
}
catch (CarIsDeadException e)
{
Console.WriteLine(e.Message);
Console.WriteLine(e.TimeStamp);
Console.WriteLine(e.Cause);
}
Console.ReadLine();
}
So, now that you understand the basic process of building a custom exception, you may wonder when you are required to do so. Typically, you only need to create custom exceptions when the error is tightly bound to the class issuing the error (for example, a custom file-centric class that throws a number of file-related errors, a Car class that throws a number of car-related errors, and so forth). In doing so, you provide the caller with the ability to handle numerous exceptions on a descriptive error-by-error basis.
234 CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING
Building Custom Exceptions, Take Two
The current CarIsDeadException type has overridden the System.Exception.Message property in order to configure a custom error message and supplied two custom properties to account for additional bits of data. In reality, however, we are not required to override the virtual Message property, as we could simply pass the incoming message to our parent’s constructor as follows:
public class CarIsDeadException : ApplicationException
{
private DateTime errorTimeStamp; private string causeOfError;
public DateTime TimeStamp
{
get { return errorTimeStamp; } set { errorTimeStamp = value; }
}
public string Cause
{
get { return causeOfError; } set { causeOfError = value; }
}
public CarIsDeadException() { }
// Feed message to parent constructor. public CarIsDeadException(string message,
string cause, DateTime time) :base(message)
{
causeOfError = cause; errorTimeStamp = time;
}
}
Notice that this time you have not defined a string variable to represent the message, and have not overridden the Message property. Rather, you are simply passing the parameter to your base class constructor. With this design, a custom exception class is little more than a uniquely named class deriving from System.ApplicationException, devoid of any base class overrides.
Don’t be surprised if most (if not all) of your custom exception classes follow this simple pattern. Many times, the role of a custom exception is not necessarily to provide additional functionality beyond what is inherited from the base classes, but to provide a strongly named type that clearly identifies the nature of the error.
Building Custom Exceptions, Take Three
If you wish to build a truly prim-and-proper custom exception class, you would want to make sure your type adheres to the exception-centric .NET best practices. Specifically, this requires that your custom exception
•Derives from Exception/ApplicationException
•Is marked with the [System.Serializable] attribute
•Defines a default constructor
CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING |
235 |
•Defines a constructor that sets the inherited Message property
•Defines a constructor to handle “inner exceptions”
•Defines a constructor to handle the serialization of your type
Now, based on your current background with .NET, you may have no idea regarding the role of attributes or object serialization, which is just fine. I’ll address these topics later in the text (see Chapter 16 for information on attributes and Chapter 21 for details on serialization services).
However, to finalize our examination of building custom exceptions, here is the final iteration of CarIsDeadException, which accounts for each of these special constructors:
[Serializable]
public class CarIsDeadException : ApplicationException
{
public CarIsDeadException() { }
public CarIsDeadException(string message) : base( message ) { } public CarIsDeadException(string message,
System.Exception inner) : base( message, inner ) { } protected CarIsDeadException(
System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context)
:base( info, context ) { }
//Any additional custom properties, constructors and data members...
}
Given that building custom exceptions that adhere to .NET best practices really only differ by their name, you will be happy to know that Visual Studio 2008 provides a code snippet template named “Exception” (see Figure 7-5), which will autogenerate a new exception class that adheres to
.NET best practices (see Chapter 2 for an explanation of code snippet templates).
Figure 7-5. The Exception code snippet template
■Source Code The CustomException project is included under the Chapter 7 subdirectory.
236 CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING
Processing Multiple Exceptions
In its simplest form, a try block has a single catch block. In reality, you often run into a situation where the statements within a try block could trigger numerous possible exceptions. Create a new C# Console Application project named ProcessMultipleExceptions, add your existing Car, Radio, and CarIsDeadException classes to the new project (via Project Add Existing Item), and update your namespace names accordingly.
Now, update the Car’s Accelerate() method to also throw a base class library–predefined ArgumentOutOfRangeException if you pass an invalid parameter (which we will assume is any value less than zero):
// Test for invalid argument before proceeding. public void Accelerate(int delta)
{
if(delta < 0)
throw new ArgumentOutOfRangeException("Speed must be greater than zero!");
...
}
The catch logic could now specifically respond to each type of exception:
static void Main(string[] args)
{
Console.WriteLine("***** Handling Multiple Exceptions *****\n");
Car myCar = new Car("Rusty", 90);
try
{
// Trip Arg out of range exception. myCar.Accelerate(-10);
}
catch (CarIsDeadException e)
{
Console.WriteLine(e.Message);
}
catch (ArgumentOutOfRangeException e)
{
Console.WriteLine(e.Message);
}
Console.ReadLine();
}
When you are authoring multiple catch blocks, you must be aware that when an exception is thrown, it will be processed by the “first available” catch. To illustrate exactly what the “first available” catch means, assume you retrofitted the previous logic with an additional catch scope that attempts to handle all exceptions beyond CarIsDeadException and ArgumentOutOfRangeException by catching a general System.Exception as follows:
// This code will not compile! static void Main(string[] args)
{
Console.WriteLine("***** Handling Multiple Exceptions *****\n");
Car myCar = new Car("Rusty", 90);
try
{
// Trip Arg out of range exception. myCar.Accelerate(-10);
CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING |
237 |
}
catch(Exception e)
{
// Process all other exceptions?
Console.WriteLine(e.Message);
}
catch (CarIsDeadException e)
{
Console.WriteLine(e.Message);
}
catch (ArgumentOutOfRangeException e)
{
Console.WriteLine(e.Message);
}
Console.ReadLine();
}
This exception-handling logic generates compile-time errors. The problem is due to the fact that the first catch block can handle anything derived from System.Exception (given the “is-a” relationship), including the CarIsDeadException and ArgumentOutOfRangeException types. Therefore, the final two catch blocks are unreachable!
The rule of thumb to keep in mind is to make sure your catch blocks are structured such that the very first catch is the most specific exception (i.e., the most derived type in an exception type inheritance chain), leaving the final catch for the most general (i.e., the base class of a given exception inheritance chain, in this case System.Exception).
Thus, if you wish to define a catch block that will handle any errors beyond CarIsDeadException and ArgumentOutOfRangeException, you would write the following:
// This code compiles just fine. static void Main(string[] args)
{
Console.WriteLine("***** Handling Multiple Exceptions *****\n");
Car myCar = new Car("Rusty", 90); try
{
// Trip Arg out of range exception. myCar.Accelerate(-10);
}
catch (CarIsDeadException e)
{
Console.WriteLine(e.Message);
}
catch (ArgumentOutOfRangeException e)
{
Console.WriteLine(e.Message);
}
//This will catch any other exception
//beyond CarIsDeadException or
//ArgumentOutOfRangeException. catch(Exception e)
{
Console.WriteLine(e.Message);
}
Console.ReadLine();
}
238 CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING
Generic catch Statements
C# also supports a “generic” catch scope that does not explicitly receive the exception object thrown by a given member:
// A generic catch.
static void Main(string[] args)
{
Console.WriteLine("***** Handling Multiple Exceptions *****\n");
Car myCar = new Car("Rusty", 90); try
{
myCar.Accelerate(90);
}
catch
{
Console.WriteLine("Something bad happened...");
}
Console.ReadLine();
}
Obviously, this is not the most informative way to handle exceptions, given that you have no way to obtain meaningful data about the error that occurred (such as the method name, call stack, or custom message). Nevertheless, C# does allow for such a construct, which can be helpful when you wish to handle all errors in a very generic fashion.
Rethrowing Exceptions
Be aware that it is permissible for logic in a try block to rethrow an exception up the call stack to the previous caller. To do so, simply make use of the throw keyword within a catch block. This passes the exception up the chain of calling logic, which can be helpful if your catch block is only able to partially handle the error at hand:
// Passing the buck.
static void Main(string[] args)
{
...
try
{
// Speed up car logic...
}
catch(CarIsDeadException e)
{
// Do any partial processing of this error and pass the buck. throw;
}
...
}
Be aware that in this example code, the ultimate receiver of CarIsDeadException is the CLR, given that it is the Main() method rethrowing the exception. Given this point, your end user is presented with a system-supplied error dialog box. Typically, you would only rethrow a partial handled exception to a caller that has the ability to handle the incoming exception more gracefully.
Also notice that we are not explicitly rethrowing the CarIsDeadException object, but rather making use of the throw keyword with no argument. Doing so preserves the context of the original target.
CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING |
239 |
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 particular 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)
{
//Throw an exception that records the new exception,
//as well as the message of the first exception. throw new CarIsDeadException(e.Message, e2);
}
}
Notice in this case, we have passed in the FileNotFoundException object as the second parameter to the CarIsDeadException constructor. Once we have configured this new object, we throw it up the call stack to the next caller, which in this case would be the Main() method.
Given that there is no “next caller” after Main() to catch the exception, we would be again presented with an error dialog box. Much like the act of rethrowing an exception, recording inner exceptions is usually only useful when the caller has the ability to gracefully catch the exception in the first place. If this is the case, the caller’s catch logic can make use of the InnerException property to extract the details of the inner exception object.
The Finally Block
A try/catch scope may also define an optional finally block. The motivation behind a finally block is to ensure that a set of code statements will always execute, exception (of any type) or not.
240CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING
To illustrate, assume you wish to always power down the car’s radio before exiting Main(), regardless of any handled exception:
static void Main(string[] args)
{
Console.WriteLine("***** Handling Multiple Exceptions *****\n");
Car myCar = new Car("Rusty", 90); myCar.CrankTunes(true);
try
{
// Speed up car logic.
}
catch(CarIsDeadException e)
{
// Process CarIsDeadException.
}
catch(ArgumentOutOfRangeException e)
{
// Process ArgumentOutOfRangeException.
}
catch(Exception e)
{
// Process any other Exception.
}
finally
{
// This will always occur. Exception or not. myCar.CrankTunes(false);
}
Console.ReadLine();
}
If you did not include a finally block, the radio would not be turned off if an exception is encountered (which may or may not be problematic). In a more real-world scenario, when you need to dispose of objects, close a file, detach from a database (or whatever), a finally block ensures a location for proper cleanup.
Who Is Throwing What?
Given that a method in the .NET Framework could throw any number of exceptions (under various circumstances), a logical question would be “How do I know which exceptions may be thrown by a given base class library method?” The ultimate answer is simple: consult the .NET Framework 3.5 SDK documentation. Each method in the help system documents the exceptions a given member may throw. As a quick alternative, Visual Studio 2008 allows you to view the list of all exceptions thrown by a base class library member (if any) simply by hovering your mouse cursor over the member name in the code window (see Figure 7-6).
CHAPTER 7 ■ UNDERSTANDING STRUCTURED EXCEPTION HANDLING |
241 |
Figure 7-6. Identifying the exceptions thrown from a given method
For those coming to .NET from a Java background, understand that type members are not prototyped with the set of exceptions it may throw (in other words, .NET does not support checked exceptions). For better or for worse, you are not required to handle each and every exception thrown from a given member. In many cases, you can handle all possible errors thrown from a set scope by catching a single System.Exception:
static void Main(string[] args)
{
try
{
File.Open("IDontExist.txt", FileMode.Open);
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
}
However, if you do wish to handle specific exceptions uniquely, just make use of multiple catch blocks as shown throughout this chapter.
The Result of Unhandled Exceptions
At this point, you might be wondering what would happen if you do not handle an exception thrown your direction. Assume that the logic in Main() increases the speed of the Car object beyond the maximum speed, without the benefit of try/catch logic. The result of ignoring an exception would be highly obstructive to the end user of your application, as an “unhandled exception” dialog box is displayed (see Figure 7-7).