C# 4 and .NET 4

362 ❘ ChaPTer 15 errOrs And exceptiOns
Modifying the Type of exception
Modifying the type of the exception can be useful when the original exception thrown does not adequately
describe the problem. What typically happens is that something — possibly the .NET runtime — throws
a fairly low-level exception that says something like an overflow occurred (OverflowException) or an
argument passed to a method was incorrect (a class derived from ArgumentException). However, because
of the context in which the exception occurred, you will know that this reveals some other underlying
problem (for example, an overflow can only happen at that point in your code because a file you have
just read contained incorrect data). In that case, the most appropriate thing that your handler for the
first exception can do is throw another exception that more accurately describes the problem, so that
another catch block further along can deal with it more appropriately. In this case, it can also forward
the original exception through a property implemented by System.Exception called InnerException.
InnerException simply contains a reference to any other related exception that was thrown — in case the
ultimate handler routine will need this extra information.
Of course, the situation also exists where an exception occurs inside a catch block. For example, you might
normally read in some configuration file that contains detailed instructions for handling the error, and it
might turn out that this file is not there.
Handling Different exceptions in Different Places
The second reason for having nested try blocks is so that different types of exceptions can be handled
at different locations in your code. A good example of this is if you have a loop where various exception
conditions can occur. Some of these might be serious enough that you need to abandon the entire loop,
whereas others might be less serious and simply require that you abandon that iteration and move on to
the next iteration around the loop. You could achieve this by having one try block inside the loop, which
handles the less serious error conditions, and an outer try block outside the loop, which handles the more
serious error conditions. You will see how this works in the next exceptions example.
user-defined eXCePTion Classes
You are now ready to look at a second example that illustrates exceptions. This example, called
SolicitColdCall, contains two nested try blocks and illustrates the practice of defining your own custom
exception classes and throwing another exception from inside a try block.
This example assumes that a sales company wants to have additional customers on its sales list. The
company’s sales team is going to phone a list of people to invite them to become customers, a practice
known in sales jargon as cold calling. To this end, you have a text file available that contains the names of
the people to be cold called. The file should be in a well-defined format in which the first line contains the
number of people in the file and each subsequent line contains the name of the next person. In other words,
a correctly formatted file of names might look like this:
4
George Washington
Benedict Arnold
John Adams
Thomas Jefferson
This version of cold calling is designed to display the name of the person on the screen (perhaps for the
salesperson to read). That is why only names and not phone numbers of the individuals are contained in the file.
For this example, your program will ask the user for the name of the file and will then simply read it in and
display the names of people. That sounds like a simple task, but even so, a couple of things can go wrong
and require you to abandon the entire procedure:
➤
The user might type the name of a file that does not exist. This will be caught as a FileNotFound
exception.
www.it-ebooks.info