The State of Client side JavaScript Error Reporting

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

by benarent • 13 years ago

38 20 13 years ago

airbrake.io

dbreaker• 13 years ago

Great approach by the airbrake team. Nice work.

benarent2• 13 years ago

Thanks dbreaker. Any questions, email me or Duncan.

tomphoolery• 13 years ago

Interesting, can't wait to try this out!

benarent2• 13 years ago

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

bvirkler• 13 years ago

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

k3n• 13 years ago

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

duncanbeevers• 13 years 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• 13 years 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• 13 years 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.

sandstrom2• 13 years 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

wbond3• 13 years 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• 13 years 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);

sandstrom2• 13 years 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• 13 years 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• 13 years 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

wbond3• 13 years ago

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.

nathan_f77• 13 years 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

russelldavis• 13 years 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/jq...

The State of Client side JavaScript Error Reporting

Related Stories