Sentry-javascript: Provide a way to disable native wrapping

Created on 25 Feb 2016  路  8Comments  路  Source: getsentry/sentry-javascript

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).

Most helpful comment

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.

All 8 comments

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

Was this page helpful?
0 / 5 - 0 ratings