Handling Exceptions in the .NET Framework
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
Exception
Try code block
Catch code block
Finally code block
Throw statement
Validation
KeyPress
ErrorProvider
Techniques you'll need to master:
Knowing the default application behavior that occurs when an unhandled exception is encountered.
Understanding the use of Try, Catch, and Finally code blocks.
Understanding the four techniques of user input validation: control choice, control state, keystroke validation, and full control validation.
In a perfect world, your code would run correctly every time. But in the real world, you need to handle unexpected problems when your code is running. The user might delete a critical file or enter invalid data. A network link to a server might fail just as you're transferring data. Or perhaps you simply didn't allow for a particular rare circumstance in your code.
Fortunately, the .NET Framework offers a robust set of tools for dealing with these unexpected problems. In this chapter, we'll look at two facets of dealing with problems in .NET. First, we'll demonstrate the programming that you can do to handle errors, allowing the user to make corrections when something goes wrong. Then, we'll demonstrate how you can use validation techniques to prevent bad data from being entered into your application in the first place. Consistent use of these techniques will help make your applications more robust and reliable.
Exceptions Overview
When an application encounters an unexpected situation (such as a missing file or input parameter) or a logical error (performing a division-by-zero operation, for example), by default the application will terminate and generate an error display like the one shown in Figure 3.1.
){kind=small}
Figure
3.1 By default, .NET displays an error message and terminates the application
when any error occurs.
Unhandled errors in an application can result in unexpected termination, lost data, and potentially even create security holes if input values are not properly restricted. The Common Language Runtime (CLR) represents all errors as exceptions. An exception is an instance of the Exception class (or a class that inherits from the Exception class). The Framework class library (FCL) includes a large number of standard exception classes that encapsulate information about common errors. Working with instances of these classes allows the developer to provide robust error-handling solutions.
The .NET Framework provides two general classes or exceptions that derive from the common Exception class:
ApplicationException—Exceptions thrown by the application.
SystemException—Exceptions thrown by the CLR.
Both of these child classes enjoy the same properties and are differentiated only in the source of the exception they represent. Table 3.1 details some of the more common properties of the Exception classes.
Table 3.1 Important Members of the Exception Class
|
Property |
Description |
|
HelpLink |
The URL for a help file associated with this exception. |
|
InnerException |
An exception associated with the exception whose InnerException property you are accessing. This is helpful when a series of exceptions are involved. Each new exception can preserve the information about the previous one by storing it in this property. |
|
Message |
A message explaining the error and possibly offering ways to resolve it. |
|
Source |
The name of the application that caused the error. |
|
StackTrace |
Specifies where the error occurred. If debugging information is available, the stack trace includes the source file and program line number, along with other information. |
|
TargetSite |
The method that threw the exception. |