Sentry-javascript: ERRO: a versão 3.23.2 causou mudança de mensagens de exceção devido ao serializador de exceção sem erro

Criado em 15 mar. 2018  ·  3Comentários  ·  Fonte: getsentry/sentry-javascript

na versão 3.23.2, o novo recurso "Sensible non-Error exception serializer" (#1253) causando erros que são feitos com es6-error (https://www.npmjs.com/package/es6-error) para alterar o conteúdo do erro.
está sendo alterado na função captureException nesta linha:

options = this._getCaptureExceptionOptionsFromPlainObject(options, ex);

para ser mais específico, aqui está o meu código:

import ExtendableError from 'es6-error'

class CustomError extends ExtendableError {
  constructor(code, message) {
    super(message)
    this.name ='CustomError'
    this.code = code
  }
}

export default CustomError

então no código:

Raven.captureException(new CustomError('code123', 'not working'));

// this will cause the error message to be "Non-Error exception captured with keys: code"

Comentários muito úteis

@zivl Quando você testa localmente e cria seu próprio arquivo custom-error.js com esse código e importa como um módulo, ele funciona corretamente.

O problema é que esta biblioteca não exporta seu código "como está", mas o pré-compila usando o Babel.

Então, acaba sendo "meio" erro, mas não realmente. É um objeto simples que herda propriedades específicas e tem um prototype definido para o próprio Error .

Infelizmente, não há como contornar isso além de alterar a ordem do cheque, pois é como um "erro de schrodinger". É e não é um erro ao mesmo tempo.

Todos 3 comentários

Esse parece ser um comportamento muito estranho dos módulos JS.

Quando você usa:

import ExtendableError from 'es6-error'

class CustomError extends ExtendableError {
  constructor(code, message) {
    super(message)
    this.name ='CustomError'
    this.code = code
  }
}

function isPlainObject(what) {
  return Object.prototype.toString.call(what) === '[object Object]';
}

function isError(value) {
  switch ({}.toString.call(value)) {
    case '[object Error]':
      return true;
    case '[object Exception]':
      return true;
    case '[object DOMException]':
      return true;
    default:
      return value instanceof Error;
  }
}

function isErrorEvent(value) {
  return Object.prototype.toString.call(value) === '[object ErrorEvent]';
}

var ex = new CustomError('code123', 'not working');

console.log('isPlainObject:', isPlainObject(ex))
console.log('isError:', isError(ex))
console.log('isErrorEvent:', isErrorEvent(ex))

Ele informará incorretamente true/true/false .

No entanto, quando você substituir a instrução import pelo próprio código

class ExtendableError extends Error {
  constructor(message = '') {
    super(message);

    // extending Error is weird and does not propagate `message`
    Object.defineProperty(this, 'message', {
      configurable: true,
      enumerable : false,
      value : message,
      writable : true,
    });

    Object.defineProperty(this, 'name', {
      configurable: true,
      enumerable : false,
      value : this.constructor.name,
      writable : true,
    });

    if (Error.hasOwnProperty('captureStackTrace')) {
      Error.captureStackTrace(this, this.constructor);
      return;
    }

    Object.defineProperty(this, 'stack', {
      configurable: true,
      enumerable : false,
      value : (new Error(message)).stack,
      writable : true,
    });
  }
}

ele informará corretamente false/true/false .

Vou tentar depurar porque é o caso e se eu não conseguir descobrir, vamos apenas trocar cheques para passar por isError primeiro.

@zivl Quando você testa localmente e cria seu próprio arquivo custom-error.js com esse código e importa como um módulo, ele funciona corretamente.

O problema é que esta biblioteca não exporta seu código "como está", mas o pré-compila usando o Babel.

Então, acaba sendo "meio" erro, mas não realmente. É um objeto simples que herda propriedades específicas e tem um prototype definido para o próprio Error .

Infelizmente, não há como contornar isso além de alterar a ordem do cheque, pois é como um "erro de schrodinger". É e não é um erro ao mesmo tempo.

@zivl lançado em 3.23.3 . Obrigado pelo relatório!

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