C# 4 and .NET 4

Catching exceptions ❘ 353
➤
arguments. Subclasses of System.SystemException include classes that represent both fatal and
nonfatal errors.
System.ApplicationException — This class is important, because it is the intended base
for any class of exception defined by third parties. If you define any exceptions covering error
conditions unique to your application, you should derive these directly or indirectly from System
.ApplicationException.
Other exception classes that might come in handy include:
➤
➤
➤
StackOverflowException — This exception is thrown when the area of memory allocated
to the stack is full. A stack overflow can occur if a method continuously calls itself recursively.
This is generally a fatal error, because it prevents your application from doing anything apart
from terminating (in which case it is unlikely that even the finally block will execute). Trying
to handle errors like this yourself is usually pointless; instead, you should get the application to
gracefully exit.
EndOfStreamException — The usual cause of an EndOfStreamException is an attempt to read
past the end of a file. A stream represents a flow of data between data sources. Streams are covered in
detail in Chapter 24, “Networking.”
OverflowException — An OverflowException is what happens if you attempt to cast an int
containing a value of -40 to a uint in a checked context.
The other exception classes shown in Figure 15-1 are not discussed here.
The class hierarchy for exceptions is somewhat unusual in that most of these classes do not add any
functionality to their respective base classes. However, in the case of exception handling, the common
reason for adding inherited classes is to indicate more specific error conditions. There is often no need to
override methods or add any new ones (although it is not uncommon to add extra properties that carry
extra information about the error condition). For example, you might have a base ArgumentException class
intended for method calls where inappropriate values are passed in, and an ArgumentNullException class
derived from it, which is intended to handle a null argument if passed.
CaTChing eXCePTions
Given that the .NET Framework includes a selection of predefined base class exception objects, how do you
use them in your code to trap error conditions To deal with possible error conditions in C# code, you will
normally divide the relevant part of your program into blocks of three different types:
➤
➤
➤
try blocks encapsulate the code that forms part of the normal operation of your program and that
might encounter some serious error conditions.
catch blocks encapsulate the code that deals with the various error conditions that your code might
have encountered by working through any of the code in the accompanying try block. This place
could also be used for logging errors.
finally blocks encapsulate the code that cleans up any resources or takes any other action that
you will normally want done at the end of a try or catch block. It is important to understand that
the finally block is executed whether or not an exception is thrown. Because the aim is that the
finally block contains cleanup code that should always be executed, the compiler will flag an error
if you place a return statement inside a finally block. For an example of using the finally block,
you might close any connections that were opened in the try block. It is also important to understand
that the finally block is completely optional. If you do not have a requirement for any cleanup code
(such as disposing or closing any open objects), then there is no need for this block.
So how do these blocks fit together to trap error conditions Here is how:
1. The execution flow first enters the try block.
2. If no errors occur in the try block, execution proceeds normally through the block, and when the
end of the try block is reached, the flow of execution jumps to the finally block if one is present
www.it-ebooks.info