I did something similar on our site a couple years ago. One nice thing about tying it into Google Analytics is you can analyze the effect of each type of error on your conversion rate, which helps prioritize your fixes.
Google Analytics works for summary-level error reporting (file, line, error message) but not very well if you want to know the details like a stack trace which can change on each occurrence. That's where the other solutions are much better. GA is certainly better than closing your eyes though.
You are right this isn't necessary a replacement for other solutions. But even if you use other logging solutions, it might be a good idea to log them in GA also so that you can measure the impact of those errors on metrics like conversions.
Yeah, there are definitely limitations. I'm going to keep playing around with the data that gets sent to Google Analytics. File/Line/Message doesn't do much (especially w/ minified js files) but there is likely a clever way to capture and log more information (navigator.* etc) or use try/catch to capture/log the stack trace. Javascript not my strongest area so slow going...
Regardless, thank you very much. Generally there is no 100% perfect solution but a copy&pasteable solution to this issue is the kind of thing I love to come across on HN.
After reading yesterdays post about client-side error tracking I started looking into leveraging Google Analytics (because obviously it would be a fast way to get some small level of error reporting up and running). There is one thing I would have to add to this topic: We decided to track these error events in a separate Google Analytics profile, because there is a 500 events per session limit: http://code.google.com/apis/analytics/docs/tracking/eventTra...
Thanks you took up on my comment and expanded this to a blog post! Where I work, we use try/catch block but they do have their drawbacks (one of them is less optimization in Chrome).
It isn't possible to have a single "wrapper" try/catch in JS, because of the event-loop nature of most JS hosts. This is because functions that are scheduled to run on the event loop (say, using a button click, or a ajax call), aren't in the same call-stack as the code that defined it. Since they aren't in the same call-stack, an outer try/catch won't work on the inner callback.
Well, in our case we work with multiples development teams, so we only "catching" errors in our code so we don't use a wrapper. If someone try it this way, I would be curious to hear about the results.
Can you go into this a bit more? errbit looks like it's airbrake compatible, and we're very happy with airbrake, even though it's JS support isn't fantastic. Can I just take errbit's notifier.js and use that? The docs dont say anything about JS...
OK, but I don't really care about the $15 per month - I really just want better JS notifications (and am perfectly happy with airbrake running the service for me).
So do they have a better JS notification? How do we use it?
window.onerror is unreliable at best. doesn't work in all browsers. doesn't capture stack information. won't give the desired result when using libraries like jquery. doesn't work particularly well with minimized code. in most (all?) versions of IE will just return "unknown error".
Using try/catch to resolve this also doesn't help unless you literally try/catch every function
There are plenty of services out there that tackle this problem properly. Shell out the money and use one.
The problem with Google Analytics is that it gives Google _all_ your weblogs. Not just your page hits but also your site _viewer's_: IP address, browser type, OS type, screen resolution, browser window size, as well as any lingering js or cookie info from their prior browsing. Google uses this data to correlate everything they can track about you, which would blow your mind if you knew what they know, then they sell this data for a substantial profit. EPIC, the EFF, and the ACLU website's go into detail about why this is decidedly not a good thing.
What I find fascinating, however, are those who ask why is that such a bad thing without, supposedly, considering the ramifications. If they ever were confronted with all that Google knows about them, from browsing to email to online purchases (not to mention their HN alias, and a fair amount of offline info too) they'd be too embarrassed to ever again
"wonder" what the problem was.
At some point the scope of Google's privacy invasion will become better known and people will think twice before even considering spyware like Google Analytics. Until then it's Google's ballgame, at least here in the US.
I tried Airbrake yesterday and it wasn't that helpful. I had to turn it off quickly as I was inundated with errors.
You can see from your screenshot that you're getting Script Error at line 0. A number of other errors pop up that I couldn't quite figure out.
For instance, when the variable 'google' isn't found it's because the google javascript never loaded. But, how many browsers are rejecting the google maps javascript?
It sounds like Airbrake was very helpful. It is telling you that users are experiencing errors frequently, something you didn't know before. If, for example, the "google javascript never loaded" situation is common you'd want to either fix that or have your own script work around it -- at the very least, let the user know why the page is broken and that it isn't your fault.
Line 0 script errors can be from dynamically loaded code, such as JSONP requests or `eval()` code.
Well... Yes. It was helpful for that reason. I waded through many of the errors and traced them back to actual lines of code. It just so happens that many of the errors weren't particularly useful to me. I.e., not actionable.
Our browser tests include IE7, IE8, IE9, Safari, Firefox and Chrome. None of those errors are present in our tests. As you note, in many of the cases I could wrap the errors with notifications to the user.
But, really, if the google variable isn't loaded for a small set of users and I can't easily configure a test system that can reproduce it, I'm not going to take the time right now. I have too many other pressing things on my list.
The "google" variable is often not loaded for people who use Adblock or similar extensions that block social media plugins. You can simply check that "google" exists before running the code that depends on it:
if (typeof google !== "undefined") {
// run google code here
google.magic();
}
I understand deadlines, and yes you may not be able to do more than explain to the user that there is a problem out of your control. But don't diss Airbrake because you don't have time to investigate and/or fix. They're not sayin' you have to fix it, they're just sayin'.
FF/Chorme/Safari also give the Line 0 "script errors" when an error occurs in any JS file that isn't on your domain (IE jquery from a CDN, 3-rd party scripts, etc). This is a cross-origin security feature.
"Script Error" at line 0 only occurs in Firefox - I know, I'm in the business of collecting errors ;). It seems to happen when the JS file couldn't be parsed correctly. The cause for this usually partially downloaded files on the client trying to be passed through the interpreter.
Other than some little HTTP tweaks that can be done, there's very little else that you can do with "Script Error"s. So, we don't even bother sending "Script Error at line 0" errors to the server. For all practical purposes, it's a meaningless error.
Two problems though:
1) no one should use Google Analytics, especially not start-ups, because it gives Google full access to intelligence that you don't want them to have.
2) I block Google Analytics because neither Google nor fly-by-night Web 2.0 startups have any business tracking that stuff. In fact it should be normal practice for all web browsers to block urchin.js by default.
If it weren't for the fact that we don't get column numbers in window.error, I would have already supported source maps in http://errorception.com/ by now. I'm still looking actively for ways to include support though.
You need to give some thought about how you categorize your events. If you plan on using events for other things, you want to give some upfront planning for how you Categorize and label things otherwise you might make reporting difficult.
