
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?

~~~
oelmekki
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)

~~~
wbond
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.

------
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...](https://github.com/getsentry/raven-
js/blob/master/plugins/jquery.js)

------
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](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
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
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
I'm curious what made you decide on rollbar out of those options?

~~~
wbond
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
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
Thanks dbreaker. Any questions, email me or Duncan.

------
tomphoolery
Interesting, can't wait to try this out!

~~~
benarent
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)

