As you have seen throughout the tour of ASP.NET, one
of the main goals is to incorporate as much of the management of Web
development as possible in ASP.NET. At this point, Microsoft Internet
Information Services (IIS) is really only a middle manager in the
overall scheme. ASP.NET now handles many facilities previously handled
exclusively by IIS (although IIS brings many ASP.NET features under its
auspices with version 7.0 running in Integrated mode). One of those
facilities is managing custom
error pages. In ASP.NET, you can introduce custom error pages instead
of allowing the client to be bombarded with ASP.NET error messages.
You can tell ASP.NET,
on encountering errors anywhere in your application, to display a
particular page by tweaking the web.config file. Table 1 shows the custom error attributes for web.config.
Table 1. Web.config Values for Setting Error Pages
Attribute | Description |
---|
defaultRedirect | Direct users here in the event of an exception. |
on/off | on = Display custom pages.
off = Display ASP.NET error pages. |
remoteOnly | Display custom errors to client, display ASP.NET errors locally. |
The following example
illustrates how to work with custom error pages. In this example, you
add some error pages to your application and see what conditions cause
them to appear.
Working with error pages
Open the DebugORama project.
Add a new Web Form named ThrowErrors.aspx to the DebugORama application.
Add two buttons: one to throw 404 errors (the nearly ubiquitous "object not found" error) and one to throw other exceptions. Set the 404 button's ID to ButtonThrow404 and set the other button's ID to ButtonThrowOther.
Add two HTML pages to your application to act as custom error pages. Name one page 404Error.htm and the other SomethingBadHappened.htm.
(This example uses straight HTML pages, although you can use ASPX files
here.) The following graphic shows the 404Error.htm file being added to
the Web solution.
Here is the SomethingBadHappened.htm page being added:
Add some content to the error
pages. The 404 error handler here displays an error message in haiku.
The other error page simply displays a label saying "Something bad
happened."
Tell ASP.NET to use the error pages by adding the customErrors section to web.config, like so:
<configuration>
<system.web>
<customErrors
defaultRedirect="SomethingBadHappened.htm" mode="On">
<error statusCode="404"
redirect="404Error.htm"/>
</customErrors>
</system.web>
</configuration>
This tells ASP.NET to show the 404Error.htm page when a file isn't found. ASP.NET will show SomethingBadHappened.htm for any other type of error.
Now
add handlers to generate the errors. Handle the 404 error button by
directing the client to a nonexistent page: In this example, there is no
page named NonExistent.aspx, so redirecting to it will cause a 404
error. Handle the second error generator by throwing a random exception.
public partial class ThrowErrors : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void ButtonThrow404_Click(object sender, EventArgs e)
{
this.Response.Redirect("NonExistent.aspx");
}
protected void ButtonThrowOther_Click(object sender, EventArgs e)
{
throw new Exception();
}
}
When you try to redirect to a nonexistent file, the "object not found" error page shows:
Throwing a generic exception causes the other page to show:
If you're running the
example in the debugger, the debugger breaks as soon as it encounters an
exception. To continue and show the error page after Visual Studio reports the exception, press F5.
In this example, the error
pages don't really help the end user because the pages do not provide
any detailed information about the exception. Your own error
pages should provide a bit more information, perhaps even a way to
contact someone for assistance. Before leaving debugging and
diagnostics, take a look at how you can trap unhandled exceptions more gracefully.