Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable for development #105

Closed
adambiggs opened this issue May 3, 2013 · 19 comments
Closed

Disable for development #105

adambiggs opened this issue May 3, 2013 · 19 comments

Comments

@adambiggs
Copy link

I'm having trouble figuring out how to restore the window.onerror event after including Raven as an AMD dependancy.

I don't want to use Raven at all during development, so I'm only calling config()/install() in production mode. But in dev mode all errors are still being thrown by TraceKit.report()... Which is pretty frustrating since the file/line number/stack trace isn't helpful anymore in the browser dev tools.

I've tried calling uninstall() in dev mode but that didn't help. Is there a reason you're binding to window.onerror no matter what instead of doing it inside config() or install()?

@adambiggs
Copy link
Author

Found a solution, but it's not ideal...

I was trying to manually set window.onerror = null in dev mode, but even that didn't work. The problem was I was require()ing Raven in a couple modules, and each time Raven was re-binding to window.onerror.

So instead I stopped using noConflict(), included it as a global dependancy in the requirejs config, and removed it as a local dependancy from the other modules. This allowed window.onerror = null to be set without Raven re-binding the event later.

Pretty messy fix though :(

@ThisIsMissEm
Copy link

@adambiggs Another solution is to create a wrapping AMD module for Raven-js which does the configure & install call, which means you only import raven-js once, but can import your own module multiple times, afaik.

I think this may be related to: #109 and #91 (comment)

@mattrobenolt
Copy link
Contributor

This shouldn't be relevant anymore. window.onerror isn't mutated until calling install() and is restored when calling uninstall(). Let me know if there's another issue.

@bobbyrenwick
Copy link

@mattrobenolt, I've upgraded to 1.1.11 and I'm not calling install() and I still end up with raven handling errors.

@mattrobenolt
Copy link
Contributor

@bobbyrenwick Can you link me to something public that is showing this happening?

@axelson
Copy link

axelson commented Nov 19, 2014

Is there a workaround for this? Even when I never call Raven.config() or Raven.install() or if I call Raven.config(false) the jquery or onerror handlers seem to be still be installed. The only workaround seems to be never loading the raven js in the first place (which is less than ideal).

@mattrobenolt
Copy link
Contributor

See: #282 :)

@axelson
Copy link

axelson commented Nov 21, 2014

Are you providing #282 as just background? I don't see any workarounds in there.

@mattrobenolt
Copy link
Contributor

Yes, because there is no solution yet.

@elsigh
Copy link

elsigh commented Jan 21, 2016

My only fix is to use require() in an if block (the rest of my code now uses import :(

@lawlmart
Copy link

lawlmart commented Jul 25, 2016

Is there an update on this?

@JoannaFalkowska
Copy link

JoannaFalkowska commented Aug 2, 2017

Any update? It STILL doesn't work correctly.

EDIT: Sorry for my tone. Had a long day.

@tremby
Copy link
Contributor

tremby commented Aug 2, 2017

What are you trying to do? I'm doing this, which is working just fine:

if (process.env.RAVEN_DSN) {
  require('raven-js').config(process.env.RAVEN_DSN, {
    environment: process.env.NODE_ENV,
  }).install();
}

Where process.env.RAVEN_DSN is the DSN of course, and which is only set when building for environments where I want Raven running, via webpack.EnvironmentPlugin.

@JoannaFalkowska
Copy link

In your version it's impossible to conditionally set up an Angular ErrorHandler. Either you set it up in every case, and then it swallows your errors no matter what, or don't but still list it in providers, which od dev causes entire module to crash.

As far as I know it's impossible to use or not use an Angular provider based on a condition.

I've done many iterations of fix attempts today.

@tremby
Copy link
Contributor

tremby commented Aug 2, 2017

To be honest that sounds to me like an Angular issue rather than a Raven one.

Having said that, I agree that a more general solution would be a good addition.

Just a thought: have you tried setting a pattern in the ignoreUrls option which matches all URLs? Would that do what you need? Something like ignoreUrls: [/./]?

Or maybe set sampleRate to zero?

@JoannaFalkowska
Copy link

It's possible to prevent Raven from sending requests and even from catching errors, but that doesn't stop the Angular ErrorHandler from swallowing errors (= at least losing track of actual lines from where errors were thrown).

I suppose you're right and it's not much of a Raven issue after all.

@paulredmond
Copy link

paulredmond commented Aug 4, 2017

For those coming here trying to figure it out still, it was a config option I missed at first shouldSendCallback:

import Raven from 'raven-js';

const env = 'prod';
const release = '12345';

Raven
  .config('https://<example>@sentry.io/1234', {
    environment: env,
    release: release,
    shouldSendCallback: () => {
      // Do your logic here...
      return ['prod', 'staging'].indexOf(env) !== -1;
    },
  })
  .install();

If shouldSendCallback is false sentry will not report. No need for conditional reporting logic in your code with this 👍 .

@davidfurlong
Copy link

Make your DSN the empty string. It will disable reporting

@paragjnath
Copy link

I have used this way. It seems working for me

if (environment.production) { Raven.config('https://@sentry.io/') .install(); }

and in providers
providers: [environment.production ? { provide: ErrorHandler, useClass: RavenErrorHandler } : [], ...

Please let me know if I am doing anything wrong here.

pcraig3 added a commit to cds-snc/ircc-rescheduler that referenced this issue Jul 17, 2018
To run sentry locally, you're going to have to run `yarn start`

Notes:
- could have also set the DSN string to empty, as per this comment
  getsentry/sentry-javascript#105 (comment)
  but not installing at all seems cleaner

Also, since sentry is client-side only, it doesn't look like it's getting
run anymore when emails fail to send.

Should really get that figured out.
pcraig3 added a commit to cds-snc/ircc-rescheduler that referenced this issue Jul 19, 2018
To run sentry locally, you're going to have to run `yarn start`

Notes:
- could have also set the DSN string to empty, as per this comment
  getsentry/sentry-javascript#105 (comment)
  but not installing at all seems cleaner

Also, since sentry is client-side only, it doesn't look like it's getting
run anymore when emails fail to send.

Should really get that figured out.
dsamojlenko pushed a commit to cds-snc/ircc-rescheduler that referenced this issue Sep 1, 2018
To run sentry locally, you're going to have to run `yarn start`

Notes:
- could have also set the DSN string to empty, as per this comment
  getsentry/sentry-javascript#105 (comment)
  but not installing at all seems cleaner

Also, since sentry is client-side only, it doesn't look like it's getting
run anymore when emails fail to send.

Should really get that figured out.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests