Friday, April 9th, 2010

ExceptionHub: Catch your site errors online or in email

Category: JavaScript, Utility

Ryan Stout (of BustaName fame) has created ExceptionHub, a place that holds JavaScript exceptions from your apps, for you to peruse.

In an attempt to make error tracking easier in JavaScript, we are releasing into beta. ExceptionHub lets you drop a few lines of code into your site and it will track all errors that occur on your page and provides you with a clean web interface to view the exceptions from. Similar exceptions are grouped together and you can see what browser and operating systems the errors occur on, as well as the page where it was triggered. Perhaps most useful of all, ExceptionHub gives you a full stack-trace of where the error happened and the functions leading up to the error.

ExceptionHub is designed to be run both in development and on a live site. Running ExceptionHub on a live site can keep informed of any broken features or browsers that don’t handle your JavaScript correctly. While it doesn’t replace testing, it does help bring peace of mind that your site is running correctly.

As the video above shows you, a snippet of code will trap exceptions and send them to exception hub, which can show you information on the error, as well as info on the user agent that caused it.

Great stuff, and a great beta. What else would you like to see?

Posted by Dion Almaer at 1:12 am

3.9 rating from 10 votes


Comments feed TrackBack URI

I guess you need to implement this before your Google Analytics tracker code?

try {
var pageTracker = _gat._getTracker(“UA-XXXXXXXX-X”);
} catch(err) {}

Comment by roosteronacid — April 9, 2010

Been there, done that. I just get an automated e-mail report when a JS error occurs on the page. I don’t need a complete interface for that.

Comment by V1 — April 9, 2010

I’d like to know how it works, is it based on the window.onerror function, or something more complicated ? I implemented such a things in the framework I’m working on, but it only works for the code executed on the page loading with try..catch

Comment by fabienmenager — April 9, 2010

Interesting … looks similar to

Comment by drwin — April 9, 2010

Got a sneak peek at the code:
It uses window.onerror only for IE despite the fact that firefox supports it? For the other browsers it wraps common interfaces such as addEventListener, setTimeout, and setInterval in try catch blocks and OVERWRITES XMLHttpRequest.prototype.send! Then it iterates over the window object wrapping almost-everything (they use an array to define the exceptions) in a try-catch block. Not sure what the deal is with opera, does an immediate return in the setup method (as if it doesn’t support opera at all) but still makes reference to it all over the place?
Seems to me like it probably does track almost every error, but its running some massive interference with native objects and I would imagine it is fantasically slow.
I wouldn’t trust it for production!

Comment by RyanMorr — April 9, 2010

btw, heres the link if your interested:

Comment by RyanMorr — April 9, 2010

Just a great idea.

Comment by jeanph01 — April 9, 2010

Yes, we do create proxy functions for some objects. Its quite simple to pass everything down and back up exactly as if you are calling the original function in a manner like below.

var wrapper = function() {
var ret = old_func.apply(this, arguments);
if (typeof(ret) !== ‘undefined’) {
return ret;

We do this to place some things in try catch blocks. While FF has an onerror, it does not return any stack trace information. Also as for performance, you have to remember that JavaScript its self is actually quite fast, its the DOM that is slow. We’ve run the wrapping code through a bunch of performance tests on all different sided sites and even on sites with a very large amount of JS it loads everything in under 5ms (usually under 3).

We have quite a few people running the beta of exceptionhub on production sites and they have not noticed any performance changes or breaking of any features.

Comment by simpleblue — April 9, 2010

@simpleblue – true no stacktrace is returned from window.onerror in firefox, but I it is worth using, it may catch an error the rest of your implementations doesn’t – which I still would want to know about it.
As for the proxy functions, I’ve always considered it best practice to not touch the native objects. You never know when your gonna run into COM objects or inaccessible properties that immediately throw errors when you try to access or manipulate them, especially if your just looping the window object and manipulating everything you find. Those are some very dangerous waters.
As for speed, I was referring to performance during runtime not the initial load, a try-catch on every function is slow:
I realize the need for such error trapping but I think if you offer more control via an API or something, it would be more suitable. Let the developer decide what functions they would like to proxy.

Comment by RyanMorr — April 9, 2010

My question is if this script is non blocking(like the latest/greatest google analytics), because you have to past the script in the head.

Comment by alfredwesterveld — April 10, 2010

Leave a comment

You must be logged in to post a comment.