How to log JavaScript errors

As with most web 2.0 platforms, a large part of the platform interaction on XING is handled via JavaScript. In total, 25,000 lines of code render dynamic content on our platform. Dragging and dropping the boxes of your start page, editing settings in your profile, a live search selecting your contacts when you type a new message – AJAX is just about everywhere.

The challenge: debugging user-sided script
Although this has many advantages, it’s also quite a challenge. In web 1.0 times, quality assurance consisted of ensuring a consistent design of the mostly static HTML on the user’s browser and debugging the code meant going through the CGI scripts running on your server – with known hardware, software and preferences.

A platform relying heavily on JavaScript changes this. The scripts run on many different browsers in many different versions whose JavaScript implementation may vary a lot. My colleague Ingo Chao wrote about the problem of degradation without grace. Now, where a non-standard interpretation of CSS might merely lead to an broken design, a script waiting for an event not set in the browser could lead to a drastically reduced functionality of some features. Plus, engineers are (despite to all rumors:) humans and thus make mistakes.

Compiling an error report
So how do we log JavaScript errors? Besides the internal testing on several browsers in different versions, we actually record all error messages that occur on the user’s side.

To do this, we use the event handler window.onerror:

window.onerror = function(errorMessage, url, line) {
  var loggerUrl = "https://www.xing.com/js/logger";
  var parameters = "?description=" + escape(errorMessage)
      + "&url=" + escape(url)
      + "&line=" + escape(line)
      + "&parent_url=" + escape(document.location.href)
      + "&user_agent=" + escape(navigator.userAgent);
 
  /** Send error to server */
  new Image().src = loggerUrl + parameters;
};

So, whenever an error occurs, we record the user’s browser, the URL of both the script file and the HTML container, the code line and the error message in a log file. Private data such as the user id, the company, a possible premium membership or anything else that falls into that category is not transmitted. We record every error, from division by zero (unless you are Chuck Norris) to infinite loops. The only errors left out are those appearing in Internet Explorer 5.5 and earlier.

Based on the above mentioned URL and error message, the server then builds a hash as a unique id for this error. The catalogized errors are counted and sorted in descending order.

A cronjob initiates that an error report showing all messages and their frequency of occurence to the frontend engineering department so the team knows where it needs to focus. This way, we receive a list of errors that are often not even perceived by the end user, and we also know which errors are most pressing.