Occasionally it happens that you pick up information from different independent sources, and you suddenly become aware, “Hey, I gotta do something about that”.
As a developer, I really like the error page in ASP.Net, since it shows you the exception (type and message), the lines in the source code that generated it, and the stack trace that led to it (the stack trace is really a plus compared to earlier programming languages I used).
Then I ran across Crash Responsibly at Coding Horror, and I remembered I recently read something on that topic at Scott’s blog. The point is:
I’m talking about catastrophic errors — real disasters. Cases where a previously unknown bug in your code causes the application to crash and burn in spectacular fashion. (…)
If users have to tell you when your app crashes, and why, you have utterly failed your users. I cannot emphasize this enough.
I think, Jeff is right. For the average user, the stack dump that I value so much is of little use. So I should handle error messages resulting from programming errors more sensibly.
The web is full of instructions how to generically handle ASP.Net exception. CodeProject has some nice articles here, here, and here.
Since I want to have my C# code in .cs files, I chose to keep code in the Global.asax to a minimum, and handle everything else in the error.aspx.cs code instead.
The key elements of exception handling are always the same:
Set up web.config to display the default ASP.Net error page if you develop on localhost, but display a “nice” error page for remote users:
<customErrors mode="RemoteOnly" defaultRedirect="error.aspx" />
The defaultRedirect value is the name of your error handling aspx page.
In global.asax, process the exception. In my implementation, I store the exception and the request that generated it in the Session object:
void Application_Error(object sender, EventArgs e)
Exception ex = Server.GetLastError();
Session["Application_Error"] = ex;
Session["Application_Request"] = Request;
Exception Handling in error.aspx
The user should get at least *some* information what happened, because I find that a constant message “Some error occurred” is little informative. So I display the exception type and message, and whether the application succeeds in notifying an administrator.
If you handle errors and exceptions, you should take care that you do not raise another exception. So everything should be triple-checked here 😉
I generate an email containing every information I can get to track down the error condition:
- Application: host and application path
- Exception object: type, message, trigger (TargetSite), stack trace
- User: current user, application-specific user information
You can fill your web.config with appSettings entries to provide additional information.
Finally, I generate an email (System.Net.Mail.MailMessage) and send it to configurable addressees.
Bugzilla uses special email headers (X-Bugzilla-*) that can be used for filtering rules in an email client. So you may choose to provide some of the collected information as email headers, using the Headers.Add method (be careful: values must not be empty strings!).
Step through every code path during development and debugging, to avoid errors in your error handling!