|Nerd programming post alert.
||[Apr. 5th, 2012|03:02 pm]
I had a coding epiphany the other day - kind of a "duh" moment. We've been doing error handling for the applications we've built for at least the last ten years or so. I get hundreds of them a day for just one of my applications. I use them as a general gage of the health of the application. If I start getting ten times as many emails for a particular type of error than usual, its a good indication that something is amiss. These emails range the gamut from 404 errors caused by search engined to genuine 500 errors as a result of an internal server error. The latter ones are sometimes difficult to track down. I send myself most of the pertinent information so I could see what the user was doing - cookies, querystring, form values, etc... But sometimes the message is cryptic like "Object reference not set to an instance of an object" or "There is no row at position 0". And without knowing what object or row they are talking about or where in the code they were when they got that error, its a bit like being blindfolded in the dark. |
Yesterday it hit me (and sorry for getting technical here). I can send along the full request headers and body that the user sent to the server when they got the error. See behind everything you type into a web browser is HTTP. Its the language (protocol actually) that handles requests and responses between your browser and the web server. If I get the raw request from the server in the error I can drop it into this tool called "Fiddler" and run that exact request against the code in my dev environment and see exactly where it craps the bed!
So far I've killed 6 or so obscure bugs. This is awesome. I look forward to seeing what else comes my way.