Sentry-javascript: キーでキャプチャされたエラー以外の例外：エラー、ヘッダー、メッセージ、名前、OK

これは、提供するオブジェクトが、Angularアプリのスタックトレースを保持するErrorインスタンスではないことを意味します。

（メッセージが示すように）必要に応じてSentry.captureException(error.error)またはSentry.captureException(error.message)使用する必要があります。

@kamilogorek oh ok）tnx

@kamilogorekは、これでもこのエラーが発生します

    const exception = error.error || error.message || error.originalError || error;
    const eventId = Sentry.captureException(exception);

+1、どのように配置してもこのエラーが発生します。

sentry.error-handler.ts

export class SentryErrorHandler extends GeneralErrorHandler {
  ...
  handleError(error) {
    ...
    const exception = error.originalError || error.error || error
    Sentry.captureException(exception)
  }
}

package.json

{
  ...
  "@angular/core": "^8.2.11",
  "@sentry/browser": "^5.7.1",
  ...
}

私はこれをすることにしました

Sentry.init({
            dsn: environment.sentryUrl,
            beforeSend(event, hint) {
                /* tslint:disable:no-string-literal only-arrow-functions */
                const isNonErrorException =
                    event.exception.values[0].value.startsWith('Non-Error exception captured') ||
                    hint.originalException['message'].startsWith('Non-Error exception captured');
                /* tslint:enable:no-string-literal only-arrow-functions */

                if (isNonErrorException) {
                    // We want to ignore those kind of errors
                    return null;
                }
                return event;
            }
        });

@gchronosの回避策をありがとうございます！ 近いうちに修正の可能性があることを願っています。

私もこれらのエラーが発生していると言ってチャイムを鳴らします。 私はAngular8を使用していますが、これに関する多くの問題を読んだ後、エラー処理コンポーネントでエラーを適切に処理していない可能性があることに気付きました。 私はcaptureExceptionに渡される前に例外を定義する他の人によって提案された回避策を試しましたが、これはエラーを減らしませんでした。 誰かがこれについてさらに意見を述べることができれば素晴らしいと思います。さもないと、GChronosの（ありがとう！）ソリューションを使用する必要があります。

+1

+1

誰かがこれをデバッグするために使用できる再現を提供できますか？ ベースのangular-cliアプリを使用しようとしましたが、この動作を再現できません。 ありがとう！

@kamilogorek新しいAngular8プロジェクトを開始し、500を返すエンドポイントに向けてhttpリクエストを行い、httpサービスでエラーをキャッチしないため、Sentryに伝播できると思います。

私はいくつかのより多くの情報でチャイムすることができます、これは私たちのErrorHandlerです：

@Injectable()
export class SentryErrorHandler implements ErrorHandler {
  constructor() { }
  handleError(error) {
    Sentry.captureException(error.originalError || error.error || error);
  }
}

セントリートラッキングでは、これらのイベントに対して常に重複するイベントが発生します。

• Object.aキーでキャプチャされたエラー以外の例外：..。
• fetchExceptionキーでキャプチャされたエラー以外の例外：..。

（他のイベントはリストの1つの項目として問題なく報告されます）

これらの「Non.Error」イベントを数百個収集しましたが、興味深いことに、これらすべてに共通するものは次のとおりです。

• browser.name：Samsung Internet 100％
• ブラウザ：Samsung Internet 9.4 100％

そして、エラーは主に次のとおりです。

{
  error: [Object], 
  headers: [Object], 
  message: Http failure during parsing for https://foo.bar/baz, 
  name: HttpErrorResponse, 
  ok: False, 
  status: 200, 
  statusText: OK, 
  url: https://foo.bar/baz
}

わかりました。SentryErrorHandlerを注入可能にし、extendsの代わりにErrorHandlerを実装しましたが、そのような問題はもうありません。
だから私はから変更しました

export class SentryErrorHandler extends ErrorHandler {

 constructor() {
     super();
 }

 handleError(err: any): void {
     if (environment.production === true || environment.preprod === true) {
         Sentry.captureMessage(err.originalError || err);
     }
     throw err;
 }
}

に

@Injectable()
export class SentryErrorHandler implements ErrorHandler {

 constructor() { }

 handleError(err: any): void {
     if (environment.production === true || environment.preprod === true) {
         Sentry.captureException(err.originalError || err);
     }
     throw err;
 }
}

最初の設定は2年間問題なく行われましたが、Angular 8にアップグレードしてから、いくつかの歩哨の例外があります。

@ jonathan-payiqこれの原因を見つけることができましたか？ それとも、これらのエラー以外の例外をすべて無視しますか？

現在、それらを無視しています。
ブレッドクラムから、これらはWebビュー/ブラウザーがバックグラウンド（非表示）にあるときに発生することがわかったため、修正は、ページが表示されていないときにフェッチが発生しないようにすることです。 どうやらSamsungブラウザはバックグラウンドでネットワークの更新をうまく処理しません。

@ jonathan-payiqどのくらい正確にそれらを無視していますか？ 前もって感謝します。

現在、以下を使用して無視しています。

Sentry.init({
  ignoreErrors: [
    'Non-Error exception captured'
  ]
});

@kamilogorek問題を再現できましたか？

元の問題が部分的に解決されたか、有効な解決策があるように思われるため、問題を解決します。 それでも問題が解決しない場合は、誰かに新しい説明を付けて新しい問題を作成してもらいたいと思います。
それでも関連性がある場合は、遠慮なくpingしてください。喜んで再開し、作業を行います。
乾杯！

解決されていません。 SentryをAngular8と統合しようとしたところ、この問題が見つかりました。

セントリーが箱から出してすぐにセットアップを主張できる方法がわかりません。それは完全に誤りです。

セントリーが箱から出してすぐにセットアップを主張できる方法がわかりません。それは完全に誤りです。

@Rushは再現可能なケースを提供します。ここでは、何が問題なのかを説明して示し、その後、私たちはあなたの主張を検証することができます。

@kamilogorek真実は、6か月以上Angularを使用していないため、確認するのに十分なレポートがここにあるため、IMOでさらに再現する必要はなく、自分で簡単に見つけることができます。 Angular v8、そして現在はv9（ソースマップなし）を使用しているプロジェクトでも同じ問題が発生しているため、そうではないことを私は知っています。

正確に、そして私は私のために仕事をするためにセントリーにお金を払っています。 手を汚すことを期待しているオープンソースプロジェクトではありません。

私はセントリーが好きですが、代わりを探すことができました...

例としてhttps://github.com/gothinkster/angular-realworld-example-appアプリを使用しました

ベアボーンクローンアプリは、SentryのAngularドキュメントに従い、ソースマップをアップロードしました。 結果は次のとおりです。

例1：壊れたロジック

Angularがエラーハンドラーで提供するもの+キャプチャするイベント：

UIでの外観：

注：AngularはErrorオブジェクト全体を処理できるため、すべてが整っているので、壊れたコードの正しい行を簡単に指すことができ、エラーメッセージとエラータイプは正しいです。

例2：壊れたサービスコール

Angularがエラーハンドラーで提供するもの+キャプチャするイベント：

UIでの外観：

注：Angularはこの情報を提供しないため、どのタイプのエラーがスローされたかを知る方法はありません。 ただし、シリアル化されたデータを見ると、「404 NotFound」エラーが発生したことがわかります。これは、無効なXHR呼び出しが原因である可能性が高いです。 次に、ブレッドクラムフローを調査して、指定されたURL（この場合はタイプミスが含まれています）へのXHR呼び出しがあり、その前に正確なDOM要素をクリックしてトリガーしたことを確認できます。 この情報があれば、99％のケースで問題を解決するのに十分なはずです。

フレームワークによって与えられたものでのみ作業できます。 それ以外の場合は、フレームワーク自体にモンキーパッチを適用する必要があります。

フレームワークによって与えられたものでのみ作業できます。 それ以外の場合は、フレームワーク自体にモンキーパッチを適用する必要があります。

これは「私たちの問題ではない」というあなたの言い方ですか？ （一部の競合他社からの）歩哨に切り替える前に、これらのXHRエラーは問題なくキャプチャされ、角度エラーハンドラーを使用した同じインストール方法を使用していました。

ベンダーとしての@kamilogorekは、フレームワークでチケットを開くこともできます。 きっと注目されると思います。

（一部の競合他社からの）歩哨に切り替える前に、これらのXHRエラーは問題なくキャプチャされ、角度エラーハンドラーを使用した同じインストール方法を使用していました。

@szechyjsは、オープンソースのSDKであり、私たちが何を目指しているかがわかっていれば、改善を繰り返すことができるので、代わりにソリューションを共有できれば素晴らしいと思います。

...フレームワークでチケットを開くこともできます。 きっと注目されると思います。

歩哨サポート付きのチケットを開いて、この問題を参照しました。

ここの通行人。 私の場合、react nativeで処理された拒否を報告したいのですが、OPと同じエラーが表示されました。 the object you provide is not an instance of Error 、以下を使って回避しました。

export interface IError extends Error {
  code?: ErrorCode
  msg?: string
}

export const appError = (code: ErrorCode, msg: string = ''): IError => {
  const errmsg = `code: ${code}, msg: ${msg}`
  const err: IError = new Error(errmsg)
  err.code = code
  err.msg = msg
  err.name = 'appError'
  return err
}

それから私は電話します

export const logError = (err: Error) => {
  sentry.captureException(err)
}

なるほど

お役に立てれば！

私の場合、SentryのBreadcrumbsセクションは、原因を特定するのに大いに役立ちました。 これは主に、一部の外部APIに404が含まれている場合に発生しました。

ドキュメントの更新と必要なJSSDKの変更が予定されています。

https://github.com/getsentry/sentry-docs/pull/1695/
https://github.com/getsentry/sentry-javascript/pull/2601

今週リリースされるはずです！ :)

これの簡単な修正（これはHTTPインターセプトエラーでのみ発生するため）：

handleError(error: Error | HttpErrorResponse | any) {
      // ... 
      if (error.constructor.name === "HttpErrorResponse") {
                error.error.Message + " (" + error.message + ")";
                error = error.error;
      }
      // ...
      Sentry.captureMessage(err.originalError || err.error || error);

     throw err;
 }

新しいドキュメントと5.16.0がリリースされました-https：//docs.sentry.io/platforms/javascript/angular/
私はそれをできるだけ明確で詳細にしようとしました、そしてそれがそれが多くのコードのように「見えるかもしれない」理由です。

@kamilogorek私もVueアプリでこの問題を抱えています。 あそこに修正はありますか？

こっちも一緒。 例外は、vuejs歩哨統合エラーハンドラーでスローされます。
https://sentry.io/share/issue/eaf13a2455e04150aaaab595d0d7bafe/

@sblawrie正確にどのような問題がありますか？ 詳細を教えてください。
@cincauhangusコードのどこかで、promiseインスタンス自体でエラーをスローしているように見えます（ abort, always, catch, doneキーに注意してください）。

何かのようなもの：

const promise = new Promise((resolve, reject) => (...));
// somehow somewhere in the code
function foo () {
  // ...
  throw promise
}

したがって、VueのerrorHandlerは、 Errorインスタンスであると想定されるpromiseオブジェクト全体を取得しています。

@kamilogorek説明してくれてありがとう。 いくつか変更を加えましたが、それでも問題が発生するかどうかを監視します。

Angular 8を使用していて、同じ問題でエラー以外の例外が発生しました。 例の「extractError」コードを次のように変更しました。

private static extractError(error: any) {
    // Try to unwrap zone.js error.
    // https://github.com/angular/angular/blob/master/packages/core/src/util/errors.ts
    if (error && error.ngOriginalError) {
      error = error.ngOriginalError;
    }
    // We can handle messages and Error objects directly.
    if (typeof error === 'string' || error instanceof Error) {
      return error;
    }
    // If it's http module error, extract as much information from it as we can.
    if (error instanceof HttpErrorResponse) {
      // The `error` property of http exception can be either an `Error` object, which we can use directly...
      if (error.error instanceof Error) {
        return error.error;
      }
      // ... or an`ErrorEvent`, which can provide us with the message but no stack...
      if (error.error instanceof ErrorEvent) {
        return error.error.message;
      }
      // ...or the request body itself, which we can use as a message instead.
      if (typeof error.error === 'string') {
        return `Server returned code ${error.status} with body "${error.error}"`;
      }
      // If we don't have any detailed information, fallback to the request message itself.
      return error.message;
    }

    // ***** CUSTOM *****
    // The above code doesn't always work since 'instanceof' relies on the object being created with the 'new' keyword
    if (error.error && error.error.message) {
      return error.error.message;
    }
    if (error.message) {
      return error.message;
    }
    // ***** END CUSTOM *****

    // Skip if there's no error, and let user decide what to do with it.
    return null;
  }

上記@untilinviteのbeforeSend例に基づいて私のSentry.init beforeSendを修正しました。 この変更は、 https：//github.com/getsentry/sentry-javascript/issues/2169からの2番目のログメッセージを処理するためのもので、これも非エラーとして解決されます。

 Sentry.init({
        dsn: AppConfig.envSettings.sentryDSN,
        maxBreadcrumbs: 50,
        environment: this.getEnvName(),
        integrations: [new Sentry.Integrations.Breadcrumbs({ console: false })],
        beforeSend(event, hint) {
          // Note: issue with double entries during http exceptions: https://github.com/getsentry/sentry-javascript/issues/2169
          // Note: issue with a second entry not being set correctly (as a non-error): https://github.com/getsentry/sentry-javascript/issues/2292#issuecomment-554932519
          const isNonErrorException = event.exception.values[0].value.startsWith('Non-Error exception captured');
          if (isNonErrorException) {
            if (!event.extra.__serialized__) {
              return null;
            }
            let realErrMsg = event.extra.__serialized__.error ? event.extra.__serialized__.error.message : null;
            realErrMsg = realErrMsg || event.extra.__serialized__.message;
            // this is a useless error message that masks the actual error.  Lets try to set it properly
            event.exception.values[0].value = realErrMsg;
            event.message = realErrMsg;
          }
          return event;
        }
      });

5.16.0リリースでドキュメントに追加された変更を加えましたが、まだNon-Error exception captured with keys: error, headers, message, name, okエラーが発生しています。 @ sentry / angularパッケージでこれらの問題が修正されることを期待していますか？

Angular：v9.1
セントリー：v5.20

@szechyjs httpインターセプターに関する2番目の部分も読みましたか？ これは通常、エラーが正しく検出されないようにする主な問題です-https ：//docs.sentry.io/platforms/javascript/angular/

@szechyjs httpインターセプターに関する2番目の部分も読みましたか？ これは通常、エラーが正しく検出されないようにする主な問題です-https ：//docs.sentry.io/platforms/javascript/angular/

インターセプターは使用していません。

こんにちは、私はこの問題にしばらく時間を費やしましたが、タイプHttpErrorResponseエラーのerror.error.messageには、必ずしも情報が含まれていないことがわかりました。 コンストラクターを見ると、AngularがメッセージpropをErrorEventではなくルートオブジェクトに設定していることがわかります。

https://github.com/angular/angular/blob/cb3db0d31b91bea14c7f567fe7e7220b9592c11b/packages/common/http/src/response.ts#L345

この行を変更することでhttps://github.com/getsentry/sentry-javascript/blob/8eb72865dcd62ff719441105c7eda28007a07e9d/packages/angular/src/errorhandler.ts#L112
に

if (error.error instanceof ErrorEvent && error.error.message)

エラーハンドラはreturn error.message;進み、予期されたエラーをスローしました。

素晴らしいキャッチ@jakkn 、ありがとう！ PRの更新されたハンドラーhttps://github.com/getsentry/sentry-javascript/pull/2903

継承したばかりのExpressアプリでこの問題が発生しています。 これがどのように発生するかはわかりませんが、アプリがスローするほとんどのエラーで発生しているようです。ドキュメントの標準のExpressセットアップを使用しています。

例： https ：

エクスプレスリクエストハンドラー用であり、Angularではありませんでしたが、これと同じエラーが発生しました。 基本的に、Errorオブジェクトの代わりにpojoを使用してnextを呼び出していました。 私は自分のエクスプレスエラーハンドラーでいくつかの楽しいことをして、それを興味深いものに変えていますが、sentryioリクエストミドルウェアが最初に実行されるため、このマーシャリングエラーは発生しませんでした。

最後に、提供されたものをより合理的なものに変えるユーティリティ関数を作成しました。

export const handleMaybeError = err => {
  if (err instanceof Error) return err
  const newErr = new Error(err.message || 'unexpected')
  for (const [key, value] of Object.entries(err)) {
    newErr[key] = value
  }
  return newErr
}

export const someController = (req, res, next) => {
  try {
    await handleResponse(req, res)
  } catch (err) {
    next(handleMaybeError(err))
  }
}

これは私が思うにスタックトレースを混乱させます、しかし実際にそれがこれに渡されたポジョであったならば、とにかくスタックトレースはありませんでした。

私たちの例では、これが修正される前は、報告されたイベントの大部分はこの特定の問題に関するものであり、長時間実行されるノードWebサーバーであるため、ブレッドクラムはほとんど役に立たず、すべてのエラーがこの1つのイベントタイプにまとめられます。

const例外= error.error || error.message || error.originalError || エラー;

これはtrue / falseに評価されます

const例外= error.error || error.message || error.originalError || エラー;

これはtrue / falseに評価されます

可能性は低いですが、可能です。 それはすべて、ストリームに送信する「エラー」に帰着します。 しかし結局のところ、これにはある種の有用な情報が含まれているはずです。