I have deployed more ASP.NET sites than I care to count. Many of these sites I was ultra confident they were error free as I'd covered every conceivable code path with error trapping and handling code. It was to my ultimate horror that when I added some simple "catch all" error handling to one of my sites, that the site was generating dozens of errors each day, and had been doing so since the site was launched months before.
I now make it standard practice that before any site that I or any of the development team I'm in creates, goes live, we add error reporting to the projects.
I have created a simple class (large - but simple) that sends the developers of a web site all the error information they could ever need to help diagnose errors that are occurring to their users.
The class has grown over about a year to it's current state, follows is a list of features: -
- Error Stack dump, with line numbers, code file, error messages and inner exception walking.
- Path details for the page that has thrown the error.
- Path details for the referrer of the page that has thrown the error.
- User's IP Address.
- The Web Server Machine name that the error occurred on (Important in Web Farm scenarios).
- Version of the .NET Framework the Application is running under.
- Version of every assembly within the Application's Application Domain, including the time it was built (Time stamp only seems to work on W2K3 not W2K)
- Full list of the content of the following collections
- Server Variables
- Full list of the content of the following state bags, including supporting the IError interface defined below.
- Trace Output (The output from ASP.NET that appears at the bottom of pages when trace="true" is specified in the Page directive, note this only shows when the trace property is set to true).
- Error Flood protection, if your site is generating lots of errors, you don't want to be swamped with e-mails so this class has the ability to send you the same error X number of times in X number of minutes, then it stops sending for X minutes.
The Error reporting code is really easy to add to your site, if you don't want granular control, all you need to do is add an entry to your ASP.NET Global.asax's Application_OnError event as follows: -
ErrorHandling.WebException WE = new ErrorHandling.WebException();
WE.CurrentException = e;
WE.MailFrom = ("email@example.com");
WE.MailTo = ("firstname.lastname@example.org");
WE.Site = ("My Web Site");
WE.FloodCount = 20;
WE.FloodMins = 5;
What the above does is send any errors to email@example.com up to a total of 20 times for each unique stack trace, over a period of 5 minutes.
There is also an interface on the Class which allows you to have any of your own objects within the State bags (Session, Application and Cache) output the custom debug information you wire in to them.
But to get to the stage of sending the errors being created in your site, you need to actually get hold of the class files, I've included them with a sample Global.asax zipped up so you can download them here.
There is only one more thing to note about this class, it has protection for "Application is Restarting" errors, we had a Web Server go loopy one day, and it sent us so many errors it killed our connection back in the office, meaning we could no longer fix the problem, the class will no longer send "Application is Restarting" errors.