figure 1: automatically handling exceptions.

(a)

function mySetTimeout(callback, timeout)

{

var wrapper = function () { try {

callback();

} catch (e) { myHandleException(e);

}

};

return (setTimeout(wrapper, timeout));

}

(b)

function myAddEventListener(obj, event, callback, capture) {

var wrapper = function (evt) { try {

callback(evt);

} catch (e) { myHandleException(e);

}

};
if ( !obj.listeners)
obj.listeners = new Array();
obj.listeners.push({
event: event,
wrapper: wrapper,
capture: capture,
callback: callback

}); obj.addEventListener(event, wrapper, capture);

}

Browser support.

Browser

Firefox 3.0.5

event

window.onerror Dom exception runtime exception user exception window.onerror Dom exception runtime exception window.onerror Dom exception runtime exception user exception window.onerror Dom exception runtime exception user exception window.onerror Dom exception runtime exception user exception

message file

x x¹ xx xx

Line

x1 x x

stack

x x2

IE 7.0.5730.13

x x x

x

x

Safari 3. 2. 1

x x

x x x

x x x

Chrome 1.0.154.36

x x

Opera 9. 63

x x

x3 x x3

1. Dom errors in Firefox do not have explicit file and line numbers, but the information is contained within the message.

2. arbitrary exceptions do not have stack traces in Firefox, but those that use the Error() constructor do.

3. opera can be configured to generate stack traces for exceptions, but it is not enabled by default.

production environment. Problems can be impossible to reproduce outside the user’s environment, and gaining access to a system for interactive debugging is often out of the question. Running test code, even without requiring downtime, can prove worse than the problem itself. For these environments, the ability to debug problems after the fact is a necessity. When a bug is encountered in production, enough information must be preserved such that the root cause can be accurately determined, and this information must be made available in a form that can be easily transported from the user to engineering.

Depending on the browser, JavaScript has a rich set of tools for identifying the bugs at the root of problems during the development phase. Tools such as Firebug, Venk-man, and built-in DOM (document object model) inspectors are immensely valuable. As with most languages, however, things become more difficult in production. Ideally, we would like to be able to obtain a complete dump of the JavaScript execution context, but no browser can support such a feature in a safe or practical manner. This leaves error messages as our only hope. These error messages must provide sufficient context to identify the root cause of an issue, and they must be integrated into the application experience such that the user can manage streams of errors and understand how to get the required information to developers for further analysis.

The first step in this process is to provide a means for displaying errors within the application. Although it is tempting simply to rely on alert() and its simple pop-up message, the visual experience associated with that is quite jarring. Large amounts of text do not scale well to pop-ups, and a flurry of such errors can require repeatedly dismissing the dialogs in rapid succession—sometimes making forward progress impossible. Many frameworks provide built-in consoles for this purpose, but a very simple hidden DOM element that allows us to expand, collapse, clear, and hide the console does the job nicely. With this integrated console, we can catch and display errors that would normally be lost to the browser error console. On