Skip to content

Why not use a default window.onError event instead of explicit try/catch? #1

meeiw opened this Issue Jan 17, 2013 · 7 comments

3 participants

meeiw commented Jan 17, 2013

Then we have a global entry point for all errors, and configuration becomes minimal.

Honeybadger member
Honeybadger member
joshuap commented Jan 17, 2013

I take that back. While the current build does support catching window.onerror events, the data that we can get back from TraceKit is much more limited than what you get if you wrap your code in a try/catch block. From TraceKit's README:

In order to get stack traces, you need to wrap your code in a try/catch block like above. Otherwise the error hits window.onerror handler and will only contain the error message, line number, and column number.

I just tried this, and while it did report the unhandled error to Honeybadger, it did not include the error class name, and only the first line of the stack trace (where the global error occurred).

I will look into a fix for this, but in the meantime my official recommendation is to use try/catch, as window.onerror seems to come with some caveats.

Sorry for the confusion!

meeiw commented Jan 19, 2013

I see. I'll try the global the handler and see if its sufficient for our app, otherwise I'll use the try/catch block


cmer commented Mar 10, 2013

Would love to be able to turn off window.onerror. I just get tons of random exceptions from 3rd party libraries sent to HB. AFAIK they don't affect our site at all...

Any ETA on this?

Honeybadger member
joshuap commented Mar 10, 2013

I'll work on this in the next couple days. I think I'm going to disable the window.onerror handler by default and add a config option to explicitly enable it.

Since it's not a very reliable way to monitor JavaScript errors, we should probably be good citizens and discourage its use. :)

@joshuap joshuap closed this in a6fb183 Mar 13, 2013
Honeybadger member
joshuap commented Mar 13, 2013

@cmer if you use the latest build, you shouldn't need to change anything else. :)

cmer commented Mar 13, 2013

Timely! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.