Every application should have error handling.  We try to trap errors using try-catch-finally block.  But what happens in the case of an unhandled exception in application?  ASP.NET produces an error page (usually located at c:\winnt\help\iishelp\common) when an application throws an unhandled exception or when we deploy an .aspx file whose source contains a syntax error without compiling it inside Visual Studio .NET first.  By default, ASP.NET displays error messages that include .NET error description along with a stack trace (see Figure 1).  There is a lot of information in the error message.  The stack trace points out the location where the specific error occurred and the last line informs us about the version used in .NET Framework.  This information is very useful for a developer because it tells why and where the error occurred.  

On the other hand, it may confuse the general user as he or she will not understand anything by seeing the displayed error message.  As a result, it may create a bad opinion in his or her mind and even may be the reason for loss of business.  Even hackers use the information displayed in the error message with a bad intention in mind as the line of code might contain confidential information, such as the password to access a database.   We do not want this page be visible to the site's visitors and we should redirect the browser to a custom error page on which we can instruct users about error causes and possible remedies.  ASP.NET provides several levels at which we can handle and respond to errors that may occur when we run an ASP.NET application.  This article will also provide some code which can be used to create custom error pages for ASP.NET web applications.  Although this article describes how to provide custom error pages and general error reporting, it is not going to describe error handling using try-catch-finally block.  The sample code snippets in this article have been written in C#.