Then we have a global entry point for all errors, and configuration becomes minimal.
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!
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
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?
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.
Closes #1: Disable window.onerror handling by default.
@cmer if you use the latest build, you shouldn't need to change anything else. :)