01101011 01101111 01100100 01101001 01101110 01100111

Capturing client-side javascript Errors

As a programmer who started on the backend, I’m used to catching, logging and reporting all the bugs there with a rich support of frameworks and techniques.

However, when it comes to frontend development, unless I’m the one who experienced the bug and my console happens to be open, I am blissfully unaware of it.

Do you deal with client-side errors? Shame on you if you don’t but luckily, we’re going to fix that today.

Google Tag Manager Javascript Error Listener

My first attempt was to utilize Google Tag Manager (GTM) and Google Analytics (GA). GA, is of course, the universal standard (one of them anyways) for tracking stats on your pages, from how many users visit to who those users are. GTM is a layer on top that lets you manage all tags on your pages, including GA tags. So if anything needs to be changed, instead of touching each and every page with GA code, you can manage it from your GTM console. You can also change your meta tags easily from the management console of GTM.

With so much power and flexibility, you’d figure Google would find a way to extend GTA and GA to log javascript errors as well. And they have.

Here’s an excellent walk through to set up GTM and GA to listen to javascript errors on all your pages without touching any code at all.

This was easy, but not as powerful as I would have liked. I would have liked to get a stack trace instead of a single message. I would like to be able to reconstruct the state or steps that the user initiated to reproduce the error.

Sentry is a major player in the error logging as a service industry. I would show you some code but unfortunately I had trouble logging errors with them. I was able to set it up so I could send messages to the backend and got to play with the interface which is really nice. But not being able to send errors defeats the purpose. Maybe you’ll have better luck.

I like them because while they are a paid service, the system is actually open-source so theoretically you could set up and maintain your own (but chances are, you won’t, which is what they’re banking on)

I should mention that by just copying the <script> tag, you’re aren’t getting the full potential of trackjs. There’s no way to capture the stacktrace for example, unless you give trackjs access to the javascript Error object. This means you need to wrap your code in a

try {... } catch {... }

But there’s an easier way.

If you’ve written object-oriented code, encapsulating your functions in object models, then you can simply “watch” those objects

var myFoo = trackJs.watchAll(new Foo());

And now, any error that happens within a function of Foo will be captured along with its stack trace and viewable in your trackjs console.

Trackjs differs from the other error logging tools in two fundamental ways, one which is a Con and the other a ProCon: They are strictly frontend javascript. So no php or even node.jsPro: You get more than error logging. They actually capture all the requests between the user and your site, so that they can reconstruct the state and steps leading up to the error for you!

For me, the pro outweighs the con. If you’re looking for a universal error logging service for all your code, front and backend, javascript and php, then I’ll suggest giving Sentry a try. If you just need javascript error logging with the ability to trace the user steps, then go with Trackjs.