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
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
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.
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:
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:
- Code to the application that triggers on the first error event.
- A sub routine that sends the details of the error to a central server.
- A server component that captures the error reports and saves them to a flat file, database, or other persistent data store.
- A reporting mechanism that notifies the support team when there's a new error to review.
Applying Error Reporting to Web Apps
The Front-end Code
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
errors that your users encounter. First, the
XMLHttpRequest object is instantiated:
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: