Log JavaScript Errors Using an AJAX-driven Web Service

There are two kinds of errors: those that the application users see and those that developers use to resolve bugs and performance issues. Typically, error messages are displayed to the end user in a message dialog or other GUI component. Those for developers, which tend to be far more detailed and technical, are logged for later review.

Until the advent of AJAX, there was no unobtrusive way to log front-end errors in web applications because JavaScript's error-capturing mechanisms were simply not advanced enough, and the language supported only the most basic I/O. Even more daunting was the fact that the producer of the application could be situated on the other side of the world! In today's article, we're going to look at a novel way to log JavaScript errors using an AJAX-driven web service.

Why Track JavaScript Errors?

As explained in my Understanding JavaScript Error Messages article, one of the most common criticisms about JavaScript is that it's painfully difficult to debug. Cryptic error messages, inconsistent error handling among browsers, combined with the option to suppress error messages, can make getting a handle on bugs a nightmare for the application support persons.

In most cases, you won't find out that your application is running into problems until frustrated customers call you up to complain that it isn't behaving the way it's supposed to. Then, the support person has to go through a tedious exercise of trying to assess the cause of the behavior via phone or email. Later, the developers have to try to reproduce the behavior as a starting point for determining what went wrong and hopefully how to repair it.

A Typical JavaScript Error

In an effort to make supporting web applications easier, developers have implemented their own error handling that presents more detailed messages, the idea being that the customer will have more valuable information to relay to the support person when they report the error. The drawback is that now the customer will see a big error message every time that one occurs, whether they like it or not and regardless of the severity of the error:

throw { name: "System Error", level: "Show Stopper", message: "Error detected. Please contact the system administrator.", htmlMessage: "Error detected. Please contact the <a href="mailto:sysadmin@acme-widgets.com">system administrator</a>." }

What is needed is a solution that will not aggravate the customer, while providing ample details to the support people in a timely fashion.

Error Reporting Components

While the practice of reporting application errors in real time to the developer(s) is nothing new, the technique could not be easily applied to web applications. It has long been an established practice to have a mechanism built into applications to email developers alerting them of a critical malfunction in the system, especially when time is a critical factor. At a minimum, most professional systems report certain event details to a log so that they can be referred to later. Error reporting in distributed applications typically consists of four components:

1. Code to the application that triggers on the first error event.
2. A sub routine that sends the details of the error to a central server.
3. A server component that captures the error reports and saves them to a flat file, database, or other persistent data store.
4. A reporting mechanism that notifies the support team when there's a new error to review.

Applying Error Reporting to Web Apps

To illustrate how the above can be accomplished using web technologies such as JavaScript and AJAX, we're going to examine just such a solution, which was submitted to me by Dorian Garson, a former Bing front-end developer and team manager at Microsoft Corporation. Dorian recently started his own web consulting firm and launched a new web site called ScriptCanary.com

The Front-end Code

Collecting the JavaScript errors is accomplished by attaching an event handler to the Window.onerror event. This small function can either be embedded in the document or stored in a separate script and added to your site documents' source code using the JavaScript src property:

<script language="JavaScript" src="ScriptCanary.js"></script>

The following code silently and automatically collects the details of JavaScript errors that your users encounter. First, the XMLHttpRequest object is instantiated:

onerror = function(d, p, l) // d: Error Description; p: Path; l: Line { //Next, we make the standard bare-JavaScript moves to get the XMLHTTPREQUEST object: try { R = new XMLHttpRequest(); } catch (e) { //swallow the error }

Then the script attempts to do a synchronous read of the problem source code file and grab the exact source lines as they appear. This guarantees that the lines will be available when it's time to view the error, and won't cause cross-site access errors when the user is reviewing the bug details later. The file is split into an array of lines so that the ones around the source of the error can be extracted:

R.open("GET", p, true); R.onreadystatechange =function(){ if (R.readyState == 4) { if (R.status == 200) { A = R.responseText.split(new RegExp("(\r\n){1}")); // Find only the lines around the error, // and insert the line numbers for (i = 0; i l - 4 && i

[next]

Find a programming school near you

Zip Code:

Subject: - Select All Subjects - Computer Applications Computer Engineering Computer Science Computer Prog. - Software Dev. Computer Game Programming Web Design Web Development Internet Systems Internet Certification Database Design and Development Information Systems Management Information Technology Project Management Network Design - Development Systems Analyst

Degree: - Select All Degrees - Associate's Bachelor's Master's Doctoral Certificates Diplomas Coursework MBA

Online Campus Both