From the similar case that you may not want to handle window.onerror, you may not want the native error wrapping (which we can consider the same thing).
Thanks David.
I took a stab at adding a config flag for the native wrapping. I'll have a quick bash at something to prevent the window.onerror
behavior too.
@dcramer I've just been looking at how we can use the same configuration to prevent attaching to window.onerror
and reading through the usage of TraceKit.
Perhaps I'm missing something, but to disable it attaching the onerror
handler it looks like we can just avoid calling TraceKit.report.subscribe
in our setup. Something like:
if (this._globalOptions.collectWindowErrors) {
TraceKit.report.subscribe(function () {
self._handleOnErrorStackInfo.apply(self, arguments);
});
}
I think our usage of TraceKit.computeStackTrace
and the call to TraceKit.report.unsubscribe
should still work just fine.
What do you think?
@davidpadbury I'm unsure at this point with how the package has evolved -- @benvinegar would know more but he's semi-afk for the next few days.
That said, the collectWindowErrors
should still work. Were you seeing otherwise?
@dcramer @benvinegar currently with collectWindowErrors
set to false
, TraceKit
will not notify it's subscribers that an unhandled error was received, so in turn these errors are not pushed to Sentry.
My problem is that it still adds a window.onerror
handler in it's subscribe method, which we always call on a Raven.install
. It just with this config doesn't call us back when an unhandled error is captured.
To give some context to my issue, we use raven-js
in a library that we publish for others to use on their sites. We'd rather not manipulate any globals at all, particularly things like window.onerror
which isn't your typical EventTarget
and can only be assigned.
Thanks @dcramer for the quick response. Have no problem waiting a few days.
I'm looking to do exactly the same as @davidpadbury - we're looking to bundle raven.js into our own lib which is then in-turn distributed and installed by customers.
I want a way to track exceptions within our plugin but without touching the customers own codebase.
@davidpadbury aside from window.onError how are you avoiding double-import of raven.js for those who already have it on their own site? name-spacing your version? (happy to chat off-list)
Hey @SirRawlins, I've just gone with not doing a Raven.install
which avoids the TraceKit bits and calling captureError
with every error we catch.
Thanks @davidpadbury I ended up using the whitelistUrls
option before install()
so that it only tracks errors inside my distributed libs filename, seems to work nicely.
To tackle raven.js being included twice should the customer already be using it in their app I check to see if Raven is defined before pulling the script in, I then instantiate a locale instance using the noConflict().
/*
*
* Raven.js error logging allows us to better track what errors
* happen to ocurr once the file is included in the wild.
*
*/
var configureRaven = function() {
// Create a noConflict in case already instantiated.
var SorryRaven = Raven.noConflict();
// Configure this instance to hit our Sentry accuont.
SorryRaven.config('https://[email protected]/74508', {
whitelistUrls: [ /status\-bar\.min\.js/ ] // Only track errors in the status bar itself.
}).install();
};
if (typeof(Raven) === "undefined") {
// Raven does not exist, we should load it ourselves
// before we configure it to catch errors.
$.getScript( "https://cdn.ravenjs.com/2.3.0/raven.min.js", function( data, textStatus, jqxhr ) {
// Raven has now been loaded and we can configure
// it to be used to catch errors.
configureRaven();
});
} else {
// Raven is already loaded into the window, use it
// to configure and catch errors for the plugin.
configureRaven();
}
Leaving that snippet here in the hope someone may find it useful or which to improve upon it.
Original issue has been already fixed
Most helpful comment
Thanks @davidpadbury I ended up using the
whitelistUrls
option beforeinstall()
so that it only tracks errors inside my distributed libs filename, seems to work nicely.To tackle raven.js being included twice should the customer already be using it in their app I check to see if Raven is defined before pulling the script in, I then instantiate a locale instance using the noConflict().
Leaving that snippet here in the hope someone may find it useful or which to improve upon it.