As of ASP v3.0 (IIS 5, Windows 2000), whenever an unhandled error occurs during the processing of an ASP page, control is passed to a page specified in the Custom Errors section of IIS's settings. The default page that is used when such an "Error 500" happens displays similar content to other pages such as the 404 - File Not Found error.
This is unhelpful for two reasons. Firstly, the page that is displayed is not very distinctive to developers due to this similarity - the relevant information is presented in a generic manner rather than one appropriate to the fact that there is an error, and more in-depth information would be beneficial. Secondly, for end users, the page displays information that they should probably not be privy to - how the page functions, what type of error has occurred, etc.
Such information could theoretically be used to gain unauthorized access to the system. This type of information should be reserved for internal development and testing purposes.
The standard 500-100.asp error page
This article looks at ways of solving both of these problems - mainly focusing on improving the feature-set and usability for the developer. The first section covers the ASPError object, which contains all of the information that is made available by ASP regarding the errors that occur.
Following that, the error pages that are displayed by .NET are described, and compared with the standard error pages. An implementation of this style of page is then given for classic ASP.
After all of the information that is available to us has been described and demonstrated, the appearance of this page is then simplified to provide more space for further functionality.
Such features as syntax highlighting of source code are also added. Following this, a method of displaying a more appropriate error page for end-users of the system is described and implemented. Extra functionality is then added - such as allowing the editing of the code on the error-page itself (along with coverage of the pitfalls associated with this), support for other devices calling the ASP page, and the e-mailing of errors to the developer.
Finally, consideration is given to further features that could be added to the error page.
With the exception of the following discussion of error trapping mechanisms available in the various languages, all of the information presented below is equally valid for ASP pages running VBScript or JScript.