Sentry-javascript: Desativar para desenvolvimento

Criado em 3 mai. 2013  ·  19Comentários  ·  Fonte: getsentry/sentry-javascript

Estou tendo problemas para descobrir como restaurar o evento window.onerror depois de incluir o Raven como uma dependência da AMD.

Eu não quero usar Raven durante o desenvolvimento, então estou apenas chamando config() / install() no modo de produção. Mas no modo dev todos os erros ainda estão sendo lançados por TraceKit.report() ... O que é bastante frustrante, já que o arquivo/número de linha/rastreamento de pilha não é mais útil nas ferramentas de desenvolvimento do navegador.

Eu tentei chamar uninstall() no modo dev, mas isso não ajudou. Existe uma razão pela qual você está vinculado a window.onerror não importa o que, em vez de fazê-lo dentro de config() ou install() ?

Comentários muito úteis

Para aqueles que vêm aqui tentando descobrir ainda, foi uma opção de configuração que eu perdi no início 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();

Se shouldSendCallback for false o sentry não reportará. Não há necessidade de lógica de relatórios condicionais em seu código com isso 👍 .

Todos 19 comentários

Encontrei uma solução, mas não é o ideal...

Eu estava tentando definir manualmente window.onerror = null no modo dev, mas mesmo isso não funcionou. O problema era que eu estava require() fazendo o Raven em alguns módulos, e cada vez que o Raven estava religando para window.onerror .

Então, em vez disso, parei de usar noConflict() , incluí-o como uma dependência global na configuração requirejs e removi-o como uma dependência local dos outros módulos. Isso permitiu que window.onerror = null fosse definido sem Raven religar o evento mais tarde.

Correção bem confusa :(

@adambiggs Outra solução é criar um módulo AMD de encapsulamento para Raven-js que faz a chamada de configuração e instalação, o que significa que você só importa o raven-js uma vez, mas pode importar seu próprio módulo várias vezes, afaik.

Acho que isso pode estar relacionado a: https://github.com/getsentry/raven-js/pull/109 e https://github.com/getsentry/raven-js/issues/91#issuecomment -15560074

Isso não deveria ser mais relevante. window.onerror não é modificado até chamar install() e é restaurado ao chamar uninstall() . Deixe-me saber se há outro problema.

@mattrobenolt , atualizei para 1.1.11 e não estou chamando install() e ainda acabo com erros de manipulação de raven.

@bobbyrenwick Você pode me vincular a algo público que está mostrando isso acontecendo?

Existe uma solução para isso? Mesmo quando eu nunca chamo Raven.config() ou Raven.install() ou se eu chamo Raven.config(false) os manipuladores jquery ou onerror parecem ainda estar instalados. A única solução parece ser nunca carregar o raven js em primeiro lugar (o que é menos que o ideal).

Veja: #282 :)

Você está fornecendo o número 282 apenas como plano de fundo? Não vejo soluções alternativas lá.

Sim, porque ainda não há solução.

Minha única correção é usar require() em um bloco if (o resto do meu código agora usa import :(

Existe uma atualização sobre isso?

Qualquer atualização? AINDA não funciona corretamente.

EDIT: Desculpe pelo meu tom. Teve um longo dia.

O que você está tentando fazer? Estou fazendo isso, que está funcionando muito bem:

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

Onde process.env.RAVEN_DSN é o DSN, claro, e que só é definido ao compilar para ambientes em que eu quero que o Raven seja executado, via webpack.EnvironmentPlugin .

Na sua versão é impossível configurar condicionalmente um Angular ErrorHandler. Ou você o configura em todos os casos e, em seguida, engole seus erros, não importa o quê, ou não, mas ainda o lista nos provedores, o que od dev faz com que todo o módulo falhe.

Até onde eu sei, é impossível usar ou não usar um provedor Angular com base em uma condição.

Eu fiz muitas iterações de tentativas de correção hoje.

Para ser honesto, isso soa para mim como uma questão Angular em vez de Raven.

Dito isto, concordo que uma solução mais geral seria um bom complemento.

Apenas um pensamento: você já tentou definir um padrão na opção ignoreUrls que corresponda a todos os URLs? Isso faria o que você precisa? Algo como ignoreUrls: [/./] ?

Ou talvez definir sampleRate para zero?

É possível evitar que o Raven envie solicitações e até mesmo capture erros, mas isso não impede o Angular ErrorHandler de engolir erros (= pelo menos perder o controle das linhas reais de onde os erros foram lançados).

Suponho que você esteja certo e não é muito um problema com Raven, afinal.

Para aqueles que vêm aqui tentando descobrir ainda, foi uma opção de configuração que eu perdi no início 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();

Se shouldSendCallback for false o sentry não reportará. Não há necessidade de lógica de relatórios condicionais em seu código com isso 👍 .

Faça do seu DSN a string vazia. Vai desabilitar os relatórios

Eu tenho usado desta forma. Parece funcionar para mim

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

e em provedores
providers: [environment.production ? { provide: ErrorHandler, useClass: RavenErrorHandler } : [], ...

Por favor, deixe-me saber se estou fazendo algo errado aqui.

Esta página foi útil?
0 / 5 - 0 avaliações