Sentry-javascript: BUG : la version 3.23.2 a provoqué la modification des messages d'exception en raison d'un sérialiseur d'exception sans erreur

Cela semble être un comportement très étrange des modules JS.

Lorsque vous utilisez :

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

Il rapportera par erreur true/true/false .

Cependant, lorsque vous remplacerez l'instruction import par le code lui-même

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,
    });
  }
}

il rapportera correctement false/true/false .

Je vais essayer de déboguer pourquoi c'est le cas et si je ne peux pas le savoir, nous échangerons simplement les chèques pour passer d'abord par isError .

@zivl Lorsque vous le testez localement et que vous créez votre propre fichier custom-error.js avec ce code et que vous l'importez en tant que module, cela fonctionne correctement.

Le problème est que cette bibliothèque n'exporte pas son code "tel quel", mais le précompile à l'aide de Babel.

Sooo ça finit par être "un peu" erreur mais pas vraiment. C'est un objet simple qui hérite de propriétés spécifiques et a un prototype défini sur le Error lui-même.

Il n'y a malheureusement pas d'autre moyen de contourner cela que de changer l'ordre des chèques, car c'est comme une "erreur de schrödinger". C'est et ce n'est pas une erreur en même temps.

@zivl est sorti en 3.23.3 . Merci pour le rapport !