

You should be using Google Analytics to log your startup's client-side errors - dclaysmith
http://www.thetaboard.com/blog/client-side-error-logging-with-google-analytics?r=378

======
dminor
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.

------
dmethvin
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.

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

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

------
zinssmeister
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...](http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html#implementationConsiderations)

------
DavidPP
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).

~~~
dclaysmith
Very clever idea (added a link to your twitter/tumblr). Do you use try/catch
in each method or a single wrapper of some sort?

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

------
nathan_f77
You can also use Errbit (<https://github.com/errbit/errbit>) to log your
client-side errors.

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

~~~
sleepyhead
Yes. Errbit is great. Replaced Airbrake for me and saved me some cash.

~~~
pbiggar
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?

~~~
sleepyhead
It works the same way as Airbrake.

------
toast76
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.

~~~
mwww
Can you recommend some of those services you are talking about?

------
pconf
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.

------
jreposa
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?

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

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

~~~
dmethvin
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'.

~~~
jreposa
Just to clarify... I love Airbrake. Apologies if it didn't come across as that
way. I use it on every site and app we create.

------
gnu8
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.

~~~
mwww
What's wrong with start-ups using GA? Aren't you a bit paranoid?

------
augustl
I wonder if there are JS minifiers that creates a symbol file so that I can
expand stack traces with it, much like compilers do.

~~~
rakeshpai
Yes there are. Google Closure compiler does export this thing called Source
Maps
([http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/))
which is very exciting.

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.

------
Kiro
Will this mess up other things in Google Analytics? Or is there any other
reason not to use this?

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

