Solid approach if you really want to dig in problems occurring client-side in projects that are still in Beta.
I'm not sure whether or not you would want this in a production page.
I'm not sure whether or not you would want this in a production page.
https://gist.github.com/2210783
Our approach integrates with a syslog-style logger. The logger preserves a ring buffer of messages, to help with debugging, since minified stack traces aren't super useful.
To mitigate the risk of a run-away infinite loop alert monster, alerts are intelligently rate limited client side. We also do server side filtering, so that known/expected errors are ignored. For example, we don't really care about Chrome extension-related failures, although I guess we might at some threshold for popular extensions.
It's relatively noisy, but so far it has been indispensable for debugging errors in production.
We don't have much noise, but we're using GWT's "unhandled exception" hook which I believe is driven by try/catch blocks on all entry points into the app. (i.e. event handlers - I think they just wrap callbacks before hooking them up.) So we only get exceptions that occur in our own code.
For us, the stacktraces are actually very useful (on the few browsers that provide traces). We dump a translation table from GWT's minification process and use it on the server side to de-obfuscate the stack traces. It works on all of the function/method names, but not local variable names.
The new javascript "source maps" technology should provide enough information to do this with any minifier or compiler. I'd expect your favorite javascript minifier to start outputting source maps in the next few months.
I do fancy the idea of logging problems client-side, because they result in users leaving your site but leaving you without a clue what happened.
The approach to rolling this out then might be to do it for only a small % of users at first so that it isn't overwhelming. You include more users as you notice that your manually created filters work.