Sentry-javascript: バグ:リリース3.23.2により、エラー以外の例外シリアライザーが原因で例外メッセージが変更されました

作成日 2018年03月15日  ·  3コメント  ·  ソース: getsentry/sentry-javascript

リリース3.23.2では、新機能「Sensible non-Error例外シリアライザー」(#1253)により、 es6-error (https://www.npmjs.com/package/es6-error)でエラーが発生します。エラーの内容を変更します。
次の行のcaptureException関数で変更されています。

options = this._getCaptureExceptionOptionsFromPlainObject(options, ex);

より具体的には、ここに私のコードがあります:

import ExtendableError from 'es6-error'

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

export default CustomError

次に、コードで:

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

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

最も参考になるコメント

@zivlローカルでテストし、そのコードを使用して独自のcustom-error.jsファイルを作成し、モジュールとしてインポートすると、正しく機能します。

問題は、このライブラリがコードを「そのまま」エクスポートせず、Babelを使用してプリコンパイルすることです。

すっごくそれは「ちょっと」エラーになってしまいますが、実際にはそうではありません。 これは、特定のプロパティを継承し、 prototypeError自体に設定されているプレーンオブジェクトです。

残念ながら、これは「シュレディンガーエラー」のようなものであるため、チェックの順序を変更する以外に方法はありません。 同時にエラーであり、エラーではありません。

全てのコメント3件

これは、JSモジュールの非常に奇妙な動作のようです。

使用する場合:

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

true/true/falseが誤って報告されます。

ただし、 importステートメントをコード自体に置き換える場合

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

false/true/falseを正しく報告します。

なぜそうなるのかをデバッグしようとします。それがわからない場合は、最初に小切手を交換してisErrorを調べます。

@zivlローカルでテストし、そのコードを使用して独自のcustom-error.jsファイルを作成し、モジュールとしてインポートすると、正しく機能します。

問題は、このライブラリがコードを「そのまま」エクスポートせず、Babelを使用してプリコンパイルすることです。

すっごくそれは「ちょっと」エラーになってしまいますが、実際にはそうではありません。 これは、特定のプロパティを継承し、 prototypeError自体に設定されているプレーンオブジェクトです。

残念ながら、これは「シュレディンガーエラー」のようなものであるため、チェックの順序を変更する以外に方法はありません。 同時にエラーであり、エラーではありません。

@zivl3.23.3でリリースされました。 報告ありがとうございます!

このページは役に立ちましたか?
0 / 5 - 0 評価