Track.js and Non-Legitimate Errors

So I've been talking about Track.js, and how it collects JavaScript errors on your site in one tidy dashboard.  It also sends you a daily summary email.  

If all the errors it sends were legitimate, everything would be great.  Unfortunately, JavaScript errors can be caused by things totally beyond-your-control.  For example, here's a recent daily report we received:

And we notice a couple of things right off the bat:

• Error messages can happen in all different languages, like Chinese.  If you can't read it, you probably have no hope of debugging it!  If this is a legitimate error, you just have to hope someone hits the same error in your native language.
• Errors can be really vague.  "Invalid procedure call or argument" might just as well read "Ooops.  Something happened."
• Errors can reference functions you've never seen before.  That syncBFPerformOnDOMChanged looks awfully strange.

Let's drill down to the error screen on that last one:

The fact that it happened in Mac OS X and Safari, but not any other browser, is a sign something might be amiss with a plugin.  If you plugin in that nasty function name into Google, you get almost no hits.   Well ... if it isn't in your code base, and it isn't in a third party library you're using, you can't do anything about this error. 

Fortunately, Track.js lets you filter out error messages that you can do nothing about.   Here's the code we use:

<script>

  window._trackJs = {

    onError: function (payload) {

       var messagesToIgnore = [

        new RegExp("ReferenceError: Can't find variable: dataKeys", "ig"),

       new RegExp("'fidoCallback' is undefined", "ig"),

new RegExp("addthis_(open|close)", "ig"),

new RegExp("Error calling method on NPObject","ig")

       ]

       for (var i=0; i < messagesToIgnore.length; i++) {

 if (messagesToIgnore[i].test(payload.message)) {

   return false;

 }

       }

       return true; 

     }

  }

</script>

That way, if we run into another problem that can do nothing about, we simply add another regular expression to this list.  You can also do more sophisticated checks like "If this happens in IE 6 or below, ignore it."

The bottom line: trying to get to 0 JavaScript errors in a public-facing site is not a good goal.  You never know what browser plugins are screwing around with your JavaScript, and you can't prevent that rogue user using Mosaic 0.1.  We've even seen BOTS that try to execute JavaScript code very naively, and barf up head-scratching errors.  

However, we've found the following strategy works great with Track.js:

• If the error rate goes up sharply on a certain day, it's worth checking out.  Usually you can trace it back to a recent production change, or a particular edge case that just happened that day.
• If someone independently reports an error your site, and they can give you a rough URL and timeframe, the Track.js dashboard can help you pinpoint it.