Comment by robocat | Hacker News Reader

Comment by robocat | Hacker News Reader

Getting the stack trace is usually painless if using jQuery. The large majority of code runs inside an event handler registered using jQuery, so there is a single place to put a try/catch within jQuery and ravenjs/getsentry do that. It also overrides window.setTimeout for the same reason.

The article doesn't mention my biggest problems:

* about half my reported exceptions are due to injected third party code. We use https, but browser extensions and plugins run JavaScript within your page. Some of the time it is obvious the exception is in third party code because of the script name or exception text, but even then it causes a lot of noise.

* With a single page app, we are extremely keen to monitor and diagnose communication problems. However often error logging will fail if the connection has failed. We use getsentry so that at least we are logging to a different domain, but ideally we need to store errors offline and forward them once getting online again.

Most of my errors are injected javascript. (not that I'm a bug free programmer, but I can fix my shit. the other stuff, it just keeps coming. and coming. It's like the fecking zombie hordes.).

It's especially fun when it's a totally useless error, like Invalid object, line 1, no file. yeah, thanks IE.

So what I've done in my window.onerror handler is enumerate all the script tags and look for ones that have a origin that's not my server. Then I send that back along with the trace of the error and all my other debugging data.

If I see a pile of scripts from google cdn and superfish and whatever, then I know that it's not my problem and if they call and bother support, support can tell them to clean up their windows install and then we'll talk.

idle speculation -- I wonder if there's a way to bugger the dom so that any script tag that's injected gets diverted to my code...

We also receive a phenomenal amount of noise due to browser extensions and so on. Switching to HTTPS helped, and so has filtering out errors from scripts on domains we don't expect (i.e. not our main domain or CDN's domain).

We also flag when we've received an error and silence reporting future errors until the page reloads, to avoid being overwhelmed.

I wish the tooling around this was better. Logging errors into an offline data store sounds sensible, and maybe something we should look at.

All good points.

Mind elaborating on the jQuery point for others? Link?

We haven't hit the other two concerns just yet but they definitely make sense. I feel that getsentry/ravenjs type products will have to offer something to filter out the noise and for offline log buffering. Both fixable, but probably not by us.

Go to https://github.com/getsentry/raven-js/blob/master/dist/1.0.8... and search for jQuery. You will see code that wraps $.event.add(), $.fn.ready(), and $.ajax()

Search for _helper('setTimeout') and _helper('setInterval') to see how it injects exception capture for those functions.

The above cover the vast majority of code entry points if using jQuery.

Reply on news.ycombinator.com