Pressing the Red Button

If you have started adding AJAX functionality into your applications, you learn real quick what your proficiency level in Javascript is. In my case, I was lacking and the inability to log or experience the javascript errors that clients were getting was frustrating. As a response, I set up a method to log the client javascript errors directly to the server. Here is the story.

When I was developing an Ajax solution for an ecommerce application, compatibility was a major factor for acceptance by the client. Since I was relatively new to Ajax and my javascript skills were nothing special (at least when I started) I was concerned that the custom javascript code I was writing would have compatibility issues with all the browser choices out there (a valid concern indeed).

So here is the problem, I wanted to be notified when my ajax functions failed on the client and I wanted details. However when javascript fails on the client only the customer sees it.

Here was my solution. First I needed a way to catch when errors ocurred on the client. Two types of errors to be exact, javascript parsing errors (from null values sneaking into your variables for example) and errors that the ajax library was returning (bad result from the server for example).

For the first type, javascript has it's own error handling functionality, so I do something like:

For the second error type, most ajax libraries have an OnError event that is called when an invalid result comes back from the server during your ajax request . Mine did, so I simlply have to specify the function that gets called when the error occurs:

Now I need a way to send those errors to my server so I get notified. I went with an old school Ajax approach but more simplified. The classic invisible IFRAME. However I don't need a result back, I just need a url request to go out and I need it to happen asyncronously (so the customer doesn't know or care).

Basically you just put an invisible iframe in the bottom of your html and write a simple function to send the result to the server. You can send anything you want to the server. I choose to send the error result that my ajax library returned. I html encoded (escaped) this error result and passed it to an aspx page. This aspx page then records the request headers so I can see what browser they are using and emails me this info and the error code that was passed as a parameter.

What better way to QA your application then having your customer do it for you (I can hear the QA managers screaming now). Anyway, this allowed me to catch errors with incompatiable browsers. Some errors I couldn't do anything about, like ajax errors from the IE 5.2 browser for Macintosh (you have to draw the line somewhere when it comes to compatiablity).

However I found a few errors with my AJAX library with the latest AOL browser. This was unaccetable, I couldn't have the latest version of AOL not working with an ecommerce site. Using the error information I recorded from the failed clients I was able to fix a bug in my third party ajax library (yeah open source!).

If you're are curious, AOL's proxy servers send back custom status messages instead of the standard "200 OK" response. Granted I had to sign up for an AOL account to reproduce and fix the problem (hey it was a free ninety day account) but the fact that I had extensive error data collected made it an easy fix. Try collecting error information from upset customers (actually you have to collect it from your upset client who collects it from his upset customers which makes it worse).

So in conclusion, collecting the client errors remotely made me feel much more confident about my ajax application and ultimately made the application more robust.

Let me know if you have any questions or comments.