The State of Client side JavaScript Error Reporting

[benarent]

http://airbrake.io/blog/notifier/state-client-side-javascript-error-reporting/

[wbond]

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?

[_pctq → wbond]

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

[wbond → _pctq]

I am filtering so only errors coming from my JS files get captured, but something in Chrome is still saying errors from other scripts are coming from mine. I know because the errors reference variables and functions that do not exist in my codebase.

I'm using this on a site with 1.5M pageviews a month, so even a very small number of errors results in quite a number of items in Rollbar. It is also effectively impossible to reproduce the issues since they are client-specific.

My current solution is to work on expanding my list of "invalid" errors that should be ignored. Based on sandstrom's comment, I'm also going to look at the Content Security Policy functionality.

[jcampbell1 → wbond]

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 → wbond]

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 → wbond]

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​ load​ing s​cript

* Synta​x err​or

[russelldavis]

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/jq...

[nathan_f77]

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

[james33]

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 → james33]

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 → jensenbox]

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 → sandstrom]

I'm curious what made you decide on rollbar out of those options?

[wbond → gingerlime]

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.

[bvirkler]

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

[k3n]

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

[duncanbeevers → k3n]

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.

[dbreaker]

Great approach by the airbrake team. Nice work.

[benarent → dbreaker]

Thanks dbreaker. Any questions, email me or Duncan.

[tomphoolery]

Interesting, can't wait to try this out!

[benarent → tomphoolery]

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