Lesson 2: Using Error Pages
The purpose of this lesson is to introduce the concept of the Error Page and highlight the role Internet Information Server (IIS) plays in error-handling configuration.
- "...because Web applications run over the Internet, there's a whole class of exceptions that can't be detected from within code. To intercept these errors and provide the best possible response, you need to use error pages."
One common example of this "whole class" is the 404, "file not found" error. This error, by definition, cannot be handled within an ASPX page since no page was found to process.
Application-wide error page configuration can be defined in the Error Mapping Properties dialogs in IIS, the Web.config file of the ASP.NET application and setting the ErrorPage attribute of the @ Page directive of a given ASPX page.
- "Using IIS to change application-wide error pages makes the changes on the server where the application is deployed. If you redeploy your application, you will have to repeat those changes for the new server using IIS. Alternatively, you can make application-wide error page settings part of your application using the project's Web.config file."
This guidance may apply to ISS 6.x and above but we may need to be aware that earlier versions of IIS might not have ASP.NET loaded or 'prioritized in the HTTP pipeline' and will intercept errors before the Web.config file is consulted.
- "Use the customErrors section in the Web.config file to specify pages to display if specific, unhandled HTTP errors occur in a Web application."
For more information on HTTP error codes, please see:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
- "The HTTP status code 500 represents an unhandled exception in the Web application. This status code can be used to present a "friendly" message to users..."
This appears to be the 'catch-all' error and handling this error should be the bare minimum for 'professional' ASP.NET applications.
- "Use the Page object's ErrorPage attribute to display a specific page when an unhandled exception occurs on a Web form. This page-level setting supersedes the application-level settings in the Web.config file."
Note that this declaration causes the error page to be loaded by redirection. All error information will be lost after redirection (so Server.GetLastError() will be undefined).