Sentry-javascript: Deshabilitar para el desarrollo

Creado en 3 may. 2013  ·  19Comentarios  ·  Fuente: getsentry/sentry-javascript

Tengo problemas para descubrir cómo restaurar el evento window.onerror después de incluir a Raven como una dependencia de AMD.

No quiero usar Raven en absoluto durante el desarrollo, así que solo estoy llamando a config() / install() en modo de producción. Pero en el modo de desarrollo TraceKit.report() siguen arrojando todos los errores... Lo cual es bastante frustrante ya que el archivo/número de línea/rastreo de pila ya no es útil en las herramientas de desarrollo del navegador.

Intenté llamar a uninstall() en modo desarrollador, pero eso no ayudó. ¿Hay alguna razón por la que está vinculado a window.onerror sin importar qué en lugar de hacerlo dentro config() o install() ?

Comentario más útil

Para aquellos que vienen aquí tratando de resolverlo todavía, fue una opción de configuración que me perdí al principio 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();

Si shouldSendCallback es false centinela no informará. No hay necesidad de lógica de informes condicionales en su código con este 👍.

Todos 19 comentarios

Encontré una solución, pero no es la ideal...

Estaba tratando de configurar manualmente window.onerror = null en modo desarrollador, pero ni siquiera eso funcionó. El problema era que estaba require() ing a Raven en un par de módulos, y cada vez que Raven se volvía a vincular a window.onerror .

Entonces, en lugar de eso, dejé de usar noConflict() , lo incluí como una dependencia global en la configuración de requirejs y lo eliminé como una dependencia local de los otros módulos. Esto permitió establecer window.onerror = null sin que Raven volviera a vincular el evento más tarde.

Sin embargo, es una solución bastante desordenada :(

@adambiggs Otra solución es crear un módulo AMD envolvente para Raven-js que realiza la llamada de configuración e instalación, lo que significa que solo importa raven-js una vez, pero puede importar su propio módulo varias veces, afaik.

Creo que esto puede estar relacionado con: https://github.com/getsentry/raven-js/pull/109 y https://github.com/getsentry/raven-js/issues/91#issuecomment -15560074

Esto ya no debería ser relevante. window.onerror no se muta hasta que se llama a install() y se restaura cuando se llama a uninstall() . Avísame si hay otro problema.

@mattrobenolt , actualicé a 1.1.11 y no estoy llamando a install() y todavía termino con errores de manejo de cuervo.

@bobbyrenwick ¿Puede vincularme a algo público que muestre que esto sucede?

¿Hay una solución para esto? Incluso cuando nunca llamo a Raven.config() o Raven.install() o si llamo a Raven.config(false) los controladores jquery u onerror parecen estar todavía instalados. La única solución parece ser nunca cargar el raven js en primer lugar (que es menos que ideal).

Ver: #282 :)

¿Está proporcionando el n.º 282 solo como fondo? No veo ninguna solución allí.

Sí, porque aún no hay solución.

Mi única solución es usar require() en un bloque if (el resto de mi código ahora usa import :(

¿Hay una actualización sobre esto?

¿Cualquier actualización? TODAVÍA no funciona correctamente.

EDITAR: Perdón por mi tono. Tuve un día largo.

¿Que estás tratando de hacer? Estoy haciendo esto, que está funcionando bien:

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

Donde process.env.RAVEN_DSN es el DSN, por supuesto, y que solo se establece cuando se crea para entornos en los que quiero que se ejecute Raven, a través webpack.EnvironmentPlugin .

En su versión, es imposible configurar condicionalmente un controlador de errores angular. O lo configura en todos los casos, y luego se traga sus errores sin importar qué, o no lo hace, pero aún lo incluye en los proveedores, lo que provoca que el módulo completo se bloquee.

Hasta donde yo sé, es imposible usar o no usar un proveedor Angular en función de una condición.

He hecho muchas iteraciones de intentos de reparación hoy.

Para ser honesto, eso me parece más un problema de Angular que de Raven.

Habiendo dicho eso, estoy de acuerdo en que una solución más general sería una buena adición.

Solo un pensamiento: ¿ha intentado establecer un patrón en la opción ignoreUrls que coincida con todas las URL? ¿Eso haría lo que necesitas? ¿Algo así como ignoreUrls: [/./] ?

¿O tal vez establecer sampleRate en cero?

Es posible evitar que Raven envíe solicitudes e incluso detecte errores, pero eso no impide que Angular ErrorHandler se trague los errores (= al menos pierda la pista de las líneas reales desde donde se generaron los errores).

Supongo que tienes razón y, después de todo, no es un gran problema de Raven.

Para aquellos que vienen aquí tratando de resolverlo todavía, fue una opción de configuración que me perdí al principio 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();

Si shouldSendCallback es false centinela no informará. No hay necesidad de lógica de informes condicionales en su código con este 👍.

Haga que su DSN sea la cadena vacía. Deshabilitará los informes.

He usado de esta manera. parece funcionar para mi

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

y en proveedores
providers: [environment.production ? { provide: ErrorHandler, useClass: RavenErrorHandler } : [], ...

Por favor, avíseme si estoy haciendo algo mal aquí.

¿Fue útil esta página
0 / 5 - 0 calificaciones