Chris Adams

If you work on sites with complex JavaScript you've probably wanted a way to know about the errors reported by users' browsers: even with a rigorous test process it's likely that there's some permutation of browser version and settings which you don't test, particularly when you consider external factors like JavaScript from third-party sources or the many ways in which anti-virus software, corporate proxies and policies can interact in darkly obscure ways.

There's now a really easy way to collect JavaScript errors thanks to Andy McKay and Clearwind Consulting: Arecibo. It's available as a commercial service for people who need support but it's also a completely open-source project on Github. Recently I've been working on an improved JavaScript client which has now merged into the official codebase, making it really easy to setup a personal error aggregation service up for all of your projects:

1. Set up an Arecibo service on AppEngine following the installation guide
2. Add this JavaScript fragment to your HTML templates:

   <script src="http://your-arecibo.appspot.com/lib/error.js" type="text/javascript" charset="utf-8"></script>
   <script type="text/javascript" charset="utf-8">
       arecibo.account = 'YOUR PUBLIC API KEY';
       arecibo.registerGlobalHandler();
   </script>
           

   It's often desirable to defer loading Arecibo until after the rest of your page has displayed which can be done using something like this example with jQuery:

   <script type="text/javascript" charset="utf-8">
       jQuery(function($) {
           $.getScript("http://your-arecibo.appspot.com/lib/error.js", function () {
               arecibo.account = 'YOUR PUBLIC API KEY';
               arecibo.registerGlobalHandler();
           });
       });
   </script>
           

The reporting interface looks like this:

There are two general caveats here: this service can't collect data when JavaScript is completely disabled or when the problem is caused by internet connectivity issues. Unfortunately browser error handling is also not standardized and WebKit browsers like Safari and Chrome currently don't have a way to capture unhandled exceptions; similarly, attempts to collect detailed stack traces varies from browser to browser so you'll find richer error reports from Firefox than Internet Explorer but in most cases simply getting the report is enough to start working on a fix or at least a more exhaustive test.