Section 7.4. Error Handling

7.4. Error Handling

You can and should avoid bugs , but there are runtime errors that cannot be avoided and should be handled as gracefully as possible. You would like to avoid having the end user see ugly or cryptic error messages, or worse , having the application crash. Errors can arise from any number of causes: user action, such as entering invalidly formatted text into a field, program logic errors, or circumstances entirely out of your control, such as an unavailable file or a downed network.

The simplest bugs to find and fix are syntaxerrors: violations of the rules of the language. For example, suppose you had the following line of code in your C# program:

 intt i; 

When you compile the program, you will get a compiler error because the keyword to declare an integer is misspelled .

Syntax errors are reduced dramatically when using VS2005. Depending on how VS2005 is configured, any code element that isn't recognized is underlined . If Auto List Members is turned on (Tools Options Text Editor All Languages), the incidence of syntax errors is further reduced.

Should any syntax errors remain or if you are using a different editor, then any syntax errors will be caught by the compiler every time you build the project. It is very difficult for a syntax error to slip by into production code.

When the compiler finds a syntax error, an error message containing the location of the error and a terse explanation will be displayed in the Output window of VS2005. If the error is caused by something such as an unbalanced parenthesis or bracket , or a missing semicolon in C#, then the actual error may not be on the exact reported line.


More problematic , and often more difficult to catch, are errors in logic . The program successfully compiles and may run perfectly well most of the time yet still contain errors in logic. The very hardest bugs to find are those that occur least often. If you can't reproduce the problem, it is terribly difficult to find it.

While you will try to eliminate all the bugs from your code, you do want your program to react gracefully when a subtle bug or unexpected problem rears its ugly head.

7.4.1. Unhandled Errors

To demonstrate what happens if there is no error handling in place, modify the sample project from this chapter to force some errors.

Go to the code-behind file. Find the for loop that populates the DropDownList in the Page_Load method. Change the test expression to cause an error intentionally at run-time. For example, change the line:

 for (i = 0; i < books.GetLength(0); i++) 

to:

 for (i = 0; i < books.GetLength(0) + 2; i++) 

When this code runs it will try to add more items than have been defined in the books array, thus causing a runtime error. This is not a subtle bug, but it serves to demonstrate how the system reacts to runtime errors.

Now run the program. As expected, an error is generated immediately, and the generic ASP.NET error page is displayed, as shown in Figure 7-19.

Figure 7-19. Generic error page

This error page is actually fairly useful to the developer or technical support person who will be trying to track down and fix any bugs. It tells you the error type, the line in the code that is the approximate error location, and a stack trace to help in tracking down how that line of code was reached.

You can replace this detailed error page with a custom error page and can control who gets to see what by setting the mode attribute of the CustomErrors element in the configuration file, as will be described next .

7.4.2. Application-Wide Error Pages

The previous section showed the default error pages presented for unhandled errors. This is fine for a developer, but if the application is in production, it would be much more aesthetically pleasing if the user were presented with an error page that looked less intimidating.

The goal is to intercept the error before it has a chance to send the generic error page to the client. This is done on an application-wide basis by modifying the configuration file, web.config , which is described more fully in Chapter 18.

The error-handling configuration information in web.config is contained within the <customErrors> section within the <system.web> section, which is contained within the <configuration> section. A typical <customErrors> section will look like Example 7-6.

Example 7-6. Custom error code snippet from web.config
 <?xml version="1.0" encoding="utf-8" ?> <configuration>    <system.web> . . .    <customErrors       defaultRedirect="CustomErrorPage.htm"       mode="On"    /> 

There are two possible attributes for the <customErrors> section: defaultRedirect and mode .

defaultRedirect is a text string that contains the URL of the page to display in the case of any error not otherwise handled. In Example 7-6, the defaultRedirect page is CustomErrorPage.htm . This example is a simple HTML page contained in the same application virtual root directory. The contents of this page are shown in Example 7-7.

Example 7-7. CustomErrorPage.htm
 <html>    <body>       <h1>Sorry - you've got an error.</h1>    </body> </html> 

If the custom error page to be displayed is not in the application virtual root, then you need to include either a relative or a fully qualified URL in the defaultRedirect attribute.

mode is an attribute that enables or disables custom error pages for the application. It can have three possible values:



On

Enables custom errors for the entire application.



Off

Disables custom errors for the entire application.



RemoteOnly

Enables custom errors only for remote clients. Local clients will see the generic error page. In this way, developers can see all the possible error information, but end users will see the custom error page.

If you edit your web.config file to look like Example 7-6, then put CustomErrorPage.htm in your application virtual root and run the program. Instead of Figure 7-19, you will see something like Figure 7-20.

Figure 7-20. Custom error page

Obviously, you'll want to put more information on your custom error page, such as instructions or contact information, but you get the idea. Showing dynamic information about the error on the custom error page is also possible.

You can even use a different custom error page for different errors. To do this, you need to include one or more <error> subtags in the <customErrors> section of web.config . You might, for example, modify web.config to look like the code snippet in Example 7-8.

Example 7-8. Custom error code snippet with <error> subtags from web.config
 <?xml version="1.0" encoding="utf-8" ?> <configuration>    <system.web> . . .    <customErrors       defaultRedirect="CustomErrorPage.htm"       mode="On" >       <error statusCode="400" redirect="CustomErrorPage400.htm"/>       <error statusCode="404" redirect="CustomErrorPage404.htm"/>       <error statusCode="500" redirect="CustomErrorPage500.htm"/>    </customErrors> 

Copy CustomErrorPage.htm three times and rename the copies to the filenames in the <error> subtags in Example 7-8. Edit the files so each displays a unique message.

Run the program again with the intentional error in the for loop still in place. You should see something like Figure 7-21.

Figure 7-21. Custom error page for Error 500

Fix the error in the for loop so the program will at least load correctly. Then run the program and click on the hyperlink you put on the test page. That control is configured to link to a nonexistent .aspx file. You should see something like Figure 7-22.

Figure 7-22. Custom error page for Error 404

Be aware that you can only display custom error pages for errors generated on your server. So, for example, if the hyperlink had been set to a nonexistent page, say, http://TestPage.comx (note the intentional misspelling of the extension), you will not see your custom error page for error 404. Instead, you'll see whatever error page for which the remote server or your browser is configured. Also, you can only trap the 404 error if the page you are trying to link to has an extension of .aspx .

In addition to displaying a custom error page, you can add code to the Application_OnError event handler in the global.asax file to be executed every time an error occurs. Application and session events, as well as the global.asax file, are discussed in detail in Chapter 18. Here would be a good place to put functionality such as logging an error message, shutting down connections, cleaning up resources, and so on.

7.4.3. Page-Specific Error Pages

You can override the application-level error pages for any specific page by modifying the Page directive. (Chapter 6 fully discusses Page directives.)

Modify the Page directive in Default.aspx file of the DebuggingApp so it appears as follows (note the highlighted ErrorPage attribute, which has been added):

 <%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false"      Inherits="DebuggingApp.WebForm1" Trace="false"  ErrorPage="PageSpecificErrorPage.aspx" %>  

If there is an error on this page, the PageSpecificErrorPage.aspx page will be displayed. If there is an application-level custom error page defined in web.config , it will be overridden by the Page directive.



Programming ASP. NET
Programming ASP.NET 3.5
ISBN: 0596529562
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net