This step-by-step guide demonstrates how to use the new ASPError object to create a custom, centralized error-handling page. For example, your application may require that someone be sent an e-mail notification when an error has occurred and some process in the system has not completed. Or, you may want to log some information to a database in addition to the Internet Information Server (IIS) error log information. For information on how to do this, see the "Error Reporting - IIS 5.0" article in the "References" section.
Microsoft Windows 2000 Professional, Windows 2000 Server, or Windows 2000 Advanced Server
Internet Information Server 5.0 installed and configured
The ASPError object and the related Active Server Pages (ASP) methods that are required to use the ASPError object are new to Active Server Pages 3.0 (ASP) and are not available on pre-Windows 2000 operating systems.
Set the New Page as the Error Handler for 500-Type Errors
On the Start menu, point to Programs, point to Administrative Tools, and then click Internet Services Manager.
Right-click the ErrTest virtual directory under the Default Web Site, and then click Properties.
On the Custom Errors tab, scroll down to an entry that includes "500;100" in the HTTP Errors column. This is where you change the setting to point to your custom error handler.
Select the line that is the current definition for 500;100 errors, and then click Edit Properties.
In the Message Type drop-down list box, click URL.
In the URL text box, notice that it points to the page at "/iisHelp/common/500-100.asp" by default. This is the default error-handling page on your system, which normally handles ASP errors if you do not define a custom handler. Note that you can open this page in a text editor to examine its error-handling techniques.
To enable your custom handler, type the virtual path to your ASP page. For example, if your ErrTest virtual directory is immediately beneath the root Web site on your server, type the following path:
Click OK twice to close the dialog boxes and set your custom error-handler.
When you are building a custom error handler, you should be aware of two additional ASP concepts: the Server.Transfer method and the Server.GetLastError method. The Server.Transfer method transfers execution to the error-handling page that is defined in your application. Because Server.Transfer occurs automatically, normally you do not have to deal with it. The Server.GetLastError method is used to return the ASPError object in your error-handling page. You do not have to use this method, and it is included in the preceding sample error-handling page. For more information about both methods, see the "References" section.
The built-in error handler can handle errors regardless of whether the page that causes the error is written in JScript or VBScript; however, the basic sample in this article only returns meaningful information about errors that come from VBScript pages. If your page is written in JScript, you may need to build an error handler that is specific to JScript; or, if you need your error handler to manage errors from any type of page, study the default error-handling page to see the techniques that are used.
Microsoft Internet Explorer 5 or later includes a setting that may override standard HTTP Web server error messages, which can lead to unexpected behavior in your browser. To turn off this feature, on the Tools menu in your browser, click Internet Options. On the Advanced tab, clear the Show Friendly HTTP Error Messages check box.
Also remember that you can still use inline error handling, and inline error handling overrides the centralized error handler. To demonstrate this, open BadPage1.asp in Notepad, and paste the following modified code, which adds an inline error handler:
<%@Language="VBSCRIPT"%><html><head><title>Bad Page 1</title></head><body><% On error resume nextResponse.Write 1/0 if err.number <> 0 then Response.Write err.description & "<BR>" & err.source & "<BR>" err.clearend if%></body></html>
Save these changes, and browse to the file in your Web browser. Notice that your inline error handler overrides the centralized error handler that you created.