Custom errors and early error-logging effort
In the beginning, webs were just "webs", webs of interconnected links to static HTML pages. Now webs resemble more of communities bustling with activities, with members of different roles, media in all forms and shapes, etc. As a web site grows more complex, the opportunities for errors and exceptions multiply. As it attracts more users, it becomes a bigger target of malicious attacks. Now it has become a must for a website to have a systematic approach to log web events, monitor the ebbs and flows of user activities, locate traffic bottlenecks, and handle exceptions and errors gracefully.
For ASP pages, programmers generally do not have many choices but sprinkle response.write statements to check the inner working mechanism of a segment of code.
With ASP .NET 1.x, programmers are equipped with a set of tools for tracing and error handling. And it became a standard to configure custom error pages whenever an error occurs. Errors are part of programming life, however it is not acceptable to have an application crash and throw at users' face an ugly yellow page filled with obtuse non-English words. It could also be dangerous, if critical technical details are exposed to "evil" eyes.
To use custom error pages, we use the customerErrors section in the web.config (For .asp pages, the way to do it is going to the IIS administration console to specify the path for different custom error pages for different error codes, however if you do not have access to the IIS, it would not be an option).
- <System.Web>
- ...
- <customErrors mode="RemoteOnly" defaultRedirect="~/Error.aspx">
- <error statusCode="404" redirect="~/Error.aspx?code=404" />
- <error statusCode="408" redirect="~/Error.aspx?code=408" />
- <error statusCode="505" redirect="~/Error.aspx?code=505" />
- </customErrors>
- ...
- </System.Web>
There are three modes in the customErrors section, Off, On and RemoteOnly. Off means to disable custom errors and show the yellow page with raw error details, which is only recommended to programmers in developing stage; On means shut off raw error message completely and display custom errors only; RemoteOnly will display designated custom error pages to remote clients, however original error pages to whoever (the debugging programmer hopefully) is using the website hosting computer.
While the customErrors section takes care of setting up a friendlier client-side front, the more important step is to log errors for later review and debugging. In ASP .NET 1.x, for logging and trapping errors, we could write some custom code in the page's Error event handler, or in a custom page base class, as in the following:
- public class BasePage: System.Web.UI.Page
- {
- protected override void OnError(EventArgs e)
- {
- HttpContext currentContext = HttpContext.Current;
- Exception exception = currentContext.Server.GetLastError ();
- string errorInfo =
- "<br>URL: " + currentContext.Request.Url.ToString () +
- "<br>Message: " + exception.Message +
- currentContext.Response.Write (errorInfo);
- }
- }
We can also trap and log error details on application level by coding the Application_Error event handler, in the Global.asax.cs code behind file:
- protected void Application_Error(Object sender, EventArgs e)
- {
- // log last exception by calling Server.GetLastError()
- }
Configuring the health monitoring system
All of the above, customErrors section in the web.config file, coding to log error details in either the Application_Error or Page_Error event handler, works for ASP.NET 1.x and above. However, with ASP .NET 2.0, there is something much better, more comprehensive and systematic. This is the health monitoring system.