4 ms·

The State of Client side JavaScript Error Reporting

38 points by benarent 13y ago

dbreaker 13y ago
Great approach by the airbrake team. Nice work.
- benarent 13y ago
  Thanks dbreaker. Any questions, email me or Duncan.
tomphoolery 13y ago
Interesting, can't wait to try this out!
- benarent 13y ago
  Thanks Tom. We really welcome your feedback, any questions or issues please open an issue on github https://github.com/airbrake/airbrake-js https://github.com/airbrake/airbrake-js
bvirkler 13y ago
Missing a closing paren on the Airbrake.try example. Otherwise, looking good!
k3n 13y ago
Does it handle uncaught errors such as a window.onerror function might do?
- duncanbeevers 13y ago
  Nope. You can attach a handler to window.onerror manually that pushes its error to the notifier, but errors handled this way won't have a stack trace.
james33 13y ago
We are currently using Sentry to handle JS error reporting. It appears that this is essentially the same thing, am I missing anything that sets it apart and makes it better?
- jensenbox 13y ago
  We use Sentry as well but I have yet to see a full stacktrace come out of it... unless I have it misconfigured or something.
  - sandstrom 13y ago
    I've tried airbrake, Errorception, Sentry/RavenJS and Rollbar, all good software that aim to solve roughly the same problem, though eventually we settled for rollbar.com
    - gingerlime 13y ago
      I'm curious what made you decide on rollbar out of those options?
      - wbond 13y ago
        I'm not the parent, but my company and I both settled on Rollbar due to fair pricing, good features and good support interactions during the beta period.
wbond 13y ago
I was hoping for some info about handling the glut of false positives in Chrome when monitoring a site for JS errors using onerror. From what I can tell, they are caused by the fact that Chrome extensions run inline on pages. It seems to me Airbrake is just requiring that you wrap all of your JS in calls to Airbrake.try(). Wouldn't this end up littering your whole app with Airbrake calls in every event handler?
- jcampbell1 13y ago
  The advantage to the try() method is you get stack traces for browsers other than Chrome. With Chrome you can get the stack trace easily. just do: window.onerror = function(msg,url,line,col,err) { console.log(err.stack) } If that doesn't work for you, you can get it like: window.onerror = function() { console.log(window.event.error.stack) } I wouldn't want litter my code with Airbrake.try(); onerror is good enough since you get stack traces from Chrome. When there is a pesky error, I tend to do something like: throw JSON.stringify(some_var_to_watch);
- sandstrom 13y ago
  I think errorception filters out most exception errors automatically [I'm not affiliated with them in any way, not even a customer]. Another option could be to disable all inline scripts via CSP, which will hit the older generation of Chrome extensions (and I think the newer ones doesn't trigger onerror).
- lucaspiller 13y ago
  Yeah we get tonnes of them, probably 90% of the Javascript errors we get are false positives (n.b. we aren't using the Airbrake service, just their gem with Errbit). Here is a sample of a few we regularly get: * Out of stack space * TypeError: Unable to delete property. * [object Event] * Error loading script * Syntax error
- oelmekki 13y ago
  To avoid that, I check origin script url, as all my scripts are within the "/assets" path : window.onerror = function( error, url, lineno ){ if ( url && url.match( //https?:\/\/.*?assets/ ) ){ # error management } } This ensure only relevant errors are included, discarding errors from extensions, trackers, gmaps, etc. Of course if you inline js for performance on production code, that's a problem. EDIT : an other important thing to avoid flooding is to handle amount of error. Javascript errors rarely come alone. An error within an event callback may be triggered several times before user surrenders. And let not even start with error within setInterval. To avoid this, I usually use a `error_got` counter and simply silence error reporting for the current page / context when I've got more than 5 errors. And about user surrendering. Reporting errors is nice. Preventing user to get stuck is better. I always automatically disable all callbacks in onerror and let default html actions on links and form being process. This ensure user intent will be fulfilled and page context will be reloaded as a bonus. I've written more extensively on this here : https://gist.github.com/oelmekki/6420982 https://gist.github.com/oelmekki/6420982
nathan_f77 13y ago
I've done a bit of work to flesh out the jQuery integration in our fork of the airbrake notifier, to automatically wrap all event handlers and AJAX callbacks. Which is great, because it means our entire Backbone app gets a full stack trace with line and column numbers. I should really submit a pull request. Also very excited about the proposals about having the error object passed to window.onerror... well, I used to be. I've had a little bit of involvement in the W3C mailing lists over the last few years, but it seems like nothing ever gets done. And source maps support would be awesome! Just as soon as we can get source maps from sprockets, which seems like it's on the way [1]. [1] https://github.com/sstephenson/sprockets/pull/311 https://github.com/sstephenson/sprockets/pull/311
russelldavis 13y ago
No need to clutter your code with a bunch of try wrappers like this suggests. There's a much better way. It turns out that in a typical web app, a handful of operations account for the vast majority of new execution contexts: - setTimeout/setInterval - event handlers - ajax response handlers Wrap those entry points (along with a single top-level wrapper which can be done as a build step) and you're almost entirely covered. If you use jQuery along with TraceKit, this plugin does it for you: https://github.com/getsentry/raven-js/blob/master/plugins/jquery.js https://github.com/getsentry/raven-js/blob/master/plugins/jq...

38 points by benarent 13y ago

dbreaker 13y ago

Great approach by the airbrake team. Nice work.

benarent 13y ago
Thanks dbreaker. Any questions, email me or Duncan.

tomphoolery 13y ago

Interesting, can't wait to try this out!

benarent 13y ago
Thanks Tom. We really welcome your feedback, any questions or issues please open an issue on github https://github.com/airbrake/airbrake-js https://github.com/airbrake/airbrake-js

bvirkler 13y ago

Missing a closing paren on the Airbrake.try example. Otherwise, looking good!

k3n 13y ago

Does it handle uncaught errors such as a window.onerror function might do?

duncanbeevers 13y ago
Nope. You can attach a handler to window.onerror manually that pushes its error to the notifier, but errors handled this way won't have a stack trace.

james33 13y ago

We are currently using Sentry to handle JS error reporting. It appears that this is essentially the same thing, am I missing anything that sets it apart and makes it better?

jensenbox 13y ago
We use Sentry as well but I have yet to see a full stacktrace come out of it... unless I have it misconfigured or something.
- sandstrom 13y ago
  I've tried airbrake, Errorception, Sentry/RavenJS and Rollbar, all good software that aim to solve roughly the same problem, though eventually we settled for rollbar.com
  - gingerlime 13y ago
    I'm curious what made you decide on rollbar out of those options?
    - wbond 13y ago
      I'm not the parent, but my company and I both settled on Rollbar due to fair pricing, good features and good support interactions during the beta period.

wbond 13y ago

I was hoping for some info about handling the glut of false positives in Chrome when monitoring a site for JS errors using onerror. From what I can tell, they are caused by the fact that Chrome extensions run inline on pages. It seems to me Airbrake is just requiring that you wrap all of your JS in calls to Airbrake.try(). Wouldn't this end up littering your whole app with Airbrake calls in every event handler?

jcampbell1 13y ago
The advantage to the try() method is you get stack traces for browsers other than Chrome. With Chrome you can get the stack trace easily. just do: window.onerror = function(msg,url,line,col,err) { console.log(err.stack) } If that doesn't work for you, you can get it like: window.onerror = function() { console.log(window.event.error.stack) } I wouldn't want litter my code with Airbrake.try(); onerror is good enough since you get stack traces from Chrome. When there is a pesky error, I tend to do something like: throw JSON.stringify(some_var_to_watch);
sandstrom 13y ago
I think errorception filters out most exception errors automatically [I'm not affiliated with them in any way, not even a customer]. Another option could be to disable all inline scripts via CSP, which will hit the older generation of Chrome extensions (and I think the newer ones doesn't trigger onerror).
lucaspiller 13y ago
Yeah we get tonnes of them, probably 90% of the Javascript errors we get are false positives (n.b. we aren't using the Airbrake service, just their gem with Errbit). Here is a sample of a few we regularly get: * Out of stack space * TypeError: Unable to delete property. * [object Event] * Error loading script * Syntax error
oelmekki 13y ago
To avoid that, I check origin script url, as all my scripts are within the "/assets" path : window.onerror = function( error, url, lineno ){ if ( url && url.match( //https?:\/\/.*?assets/ ) ){ # error management } } This ensure only relevant errors are included, discarding errors from extensions, trackers, gmaps, etc. Of course if you inline js for performance on production code, that's a problem. EDIT : an other important thing to avoid flooding is to handle amount of error. Javascript errors rarely come alone. An error within an event callback may be triggered several times before user surrenders. And let not even start with error within setInterval. To avoid this, I usually use a `error_got` counter and simply silence error reporting for the current page / context when I've got more than 5 errors. And about user surrendering. Reporting errors is nice. Preventing user to get stuck is better. I always automatically disable all callbacks in onerror and let default html actions on links and form being process. This ensure user intent will be fulfilled and page context will be reloaded as a bonus. I've written more extensively on this here : https://gist.github.com/oelmekki/6420982 https://gist.github.com/oelmekki/6420982

nathan_f77 13y ago

I've done a bit of work to flesh out the jQuery integration in our fork of the airbrake notifier, to automatically wrap all event handlers and AJAX callbacks. Which is great, because it means our entire Backbone app gets a full stack trace with line and column numbers. I should really submit a pull request. Also very excited about the proposals about having the error object passed to window.onerror... well, I used to be. I've had a little bit of involvement in the W3C mailing lists over the last few years, but it seems like nothing ever gets done. And source maps support would be awesome! Just as soon as we can get source maps from sprockets, which seems like it's on the way [1]. [1] https://github.com/sstephenson/sprockets/pull/311 https://github.com/sstephenson/sprockets/pull/311

russelldavis 13y ago

No need to clutter your code with a bunch of try wrappers like this suggests. There's a much better way. It turns out that in a typical web app, a handful of operations account for the vast majority of new execution contexts: - setTimeout/setInterval - event handlers - ajax response handlers Wrap those entry points (along with a single top-level wrapper which can be done as a build step) and you're almost entirely covered. If you use jQuery along with TraceKit, this plugin does it for you: https://github.com/getsentry/raven-js/blob/master/plugins/jquery.js https://github.com/getsentry/raven-js/blob/master/plugins/jq...