Sentry-javascript: スローされたすべてのエラーを自動的にログに記録しますか?

作成日 2013年02月10日  ·  31コメント  ·  ソース: getsentry/sentry-javascript

Ravenにスローされたすべてのエラーをログに記録させる方法はありますか? 何らかの理由で、いくつかのthrow呼び出しをログに記録しますが、他の呼び出しはログに記録しません。 コールスタックのさらに下にネストされている動作はログに記録されない傾向があることがわかりました。

最も参考になるコメント

どうぞ:

var __hasProp = {}.hasOwnProperty,
  __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };

window.Error = (function(_super) {

  __extends(_Class, _super);

  function _Class() {
    var error;
    error = _Class.__super__.constructor.apply(this, arguments);
    Raven.captureException(error);
    return error;
  }

  return _Class;

})(Error);

全てのコメント31件

ハハ、Javascriptでのエラー処理は本当にひどいです。 エラーをスローする方法の例を教えてください。

たとえば、文字列をスローしても、送信されたメッセージ以外の情報を取得することはできません。 実際のErrorオブジェクトを使用して、スタックを取得する(試行する)ことができます。

したがって、情報が多ければ多いほど、これには適しています。

それはそう。

私は次のようなエラーをスローしています:

throw new Error("Error");

歩哨にログインすることもあれば、ログインしないこともあります。

これはどこかで見ることができるページにありますか? それともどこかに置くことができますか? 正直なところ、それだけでは十分な情報ではありません。 エラーがログに記録されない理由には約10の要因があり、それらのほとんどは私たちの手に負えません。 :)それで、私が完全な文脈を見ることができるならば、私はあなたにブラウザを助けるための提案を与えることができます。

アプリは実際にはrequire.jsを使用してJavaScriptにコンパイルされるCoffeeScriptで記述されています。 メインのエントリポイントは次のようになります。

Raven.config('http://[email protected]');
Raven.context(function() {
  define(['cs!csmain']);
});

contextラッパーなしでも試してみましたが、何も変わらないようです。 コールスタックの上位で行われたthrowの呼び出しは引き続きログに記録されますが、下位の呼び出しは無視されます。

Raven.install()を実行していますか

また、require.jsの場合、モジュールを明示的にラップしたい場合は、次のようにします。

define(['module'], Raven.wrap(function(module) {
  // insert cool stuff here
}));

スニペットで忘れましたが、 config() $の後に$ install()を呼び出しています

モジュールをラップアラウンドしようとしたことはありませんが、すでに一部の場所で機能しているのか、他の場所では機能していないのかを考えました。

それはすべて、実際にはコールスタックに依存します。 物事が非同期の土地に入り始めるとき、それは荒くなります。 たとえば、これは期待どおりには機能しません。

Raven.context(function() {
  setTimeout(function() {
    throw new Error('crap');
  }, 1);
});

内部関数は、メインコンテキスト外の独自のコンテキストで実行されます。 Node.jsは「ドメイン」と呼ばれるものでこれを解決しますが、残念ながら、それらはブラウザーの世界には存在しません。

したがって、エラーが検出されず、一番上までバブルした場合、その時点では100%価値がないため、通常は拒否されます。

ああ、なるほど。 おそらくwindow.onerrorを利用する方法がありますか?

FWIWは、可能であれば、例外をキャプチャする最も確実な方法は、明示的にRaven.captureExceptionを使用することです。 それが常に実行可能であるとは限らないことを理解していますが、参考までに。

したがって、明示的な試行...ブロックを除いて、信頼できるmosは次のとおりです。

try {
  throw new Error('something');
} catch(e) {
  Raven.captureException(e);
}

右。 もちろん、エラーを自動的にキャプチャするのは素晴らしいことですが、JavaScriptではゲームを簡単にプレイすることはできません...

@pheuterいいえ。 :)そしてそれは楽しい部分です。 エラーがwindow.onerrorに到達すると、それは実際のErrorオブジェクトではなくなります。 それはただ役に立たないひもに平らになります。 また、クロスドメインのセキュリティ問題も発生します。 したがって、基本的に、エラーがwindow.onerrorに達すると、私たちが持っている情報は"Script error."しかないため、通常は破棄されます。

吸う。 まあ、説明に感謝します!

いいえ、Javascriptはそうではありません。 実際、それは本当にひどいです。 :)私は、ブラウザを活用してより良い情報を提供する方法を積極的に調査しています。 このアイデアは、モンキーパッチFunction.prototype.callにさえ頭を悩ませました。 しかし、それはおそらく本当に悪いニュースです。

完全に! ドキュメントを明確にするための推奨事項や提案があれば、私に知らせてください。 私はいつもそのようなものを探しています。

構成と使用法のドキュメントは非常に単純で、簡単に理解できます。

これを機能させるためにErrorを拡張する方法があるのだろうか。

@mattrobenolt 、これはCoffeeScriptを使用して採用しているアプローチです。

window.Error = class extends Error
  constructor: ->
    error = super
    Raven.captureException error
    return error

次に、 throw new Error "Test Error"を使用します

明確にするために上記のコメントを更新しました。

うーん。 週末にこれで遊んでみます。 最後に試しましたが、window.Errorにパッチを適用できませんでした。 もっと多くのブラウザで再試行して、何が可能かを確認します。

ヘッドアップをありがとう!

また、通常のJavascriptでそれを教えてもらえますか? 私はそれが何をしているのかかなり確信しています、私はただ再確認したいだけです。 私はCoffeescriptを書きません。

どうぞ:

var __hasProp = {}.hasOwnProperty,
  __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };

window.Error = (function(_super) {

  __extends(_Class, _super);

  function _Class() {
    var error;
    error = _Class.__super__.constructor.apply(this, arguments);
    Raven.captureException(error);
    return error;
  }

  return _Class;

})(Error);

今考えてみると、これは欠陥のあるアプローチです。 コンストラクターをオーバーライドするだけで、Ravenは、スローされたかどうかに関係なく、すべてのエラーオブジェクトをキャプチャします。 :)

参考までに、エラーセプションはこれを処理する方法を見つけました。 raven-jsが同じことを行うことができれば、かっこいいでしょう。

@dmcquayErrorceptionがキャプチャする例を提供できますか? おそらくリバースエンジニアリングできます。

私は実際、すべてのJSエラーハンドラーが50%raven.jsであると想定しています;)

:うんこ:

@BYK 、何かアイデアはありますか?

私はエラー受容についての内部知識を持っていません。 私はサービスを使用していますが、宣伝どおりに機能しているようです。 知っているのはそれだけ。

それらがどのように機能するかを調べたところ、 window.onerrorに接続しているだけで、スタックトレースは気にしないようです。 少なくともこの種のものについては。

ErrorオブジェクトのハイジャックはFirefoxで機能しますが、 @ mattrobenoltがそれらすべてをキャプチャすることについてのポイントは、スローされていないものも有効な懸念事項です。

これに対する厄介な回避策は、グローバルコンストラクターをハイジャックして作成されたErrorインスタンスを格納し、 onerrorをリッスンして、 messagefileName 、およびlineNoを比較することです。保存されたErrorオブジェクトのプロパティを持つ

すべてのエラー通知サービスを評価しているときに、一部のJavascript固有のサービス(https://qbaka.com/など)がスタックトレースを追跡し、特定のエラーの原因となったユーザーアクションを表示することに気付きました。 それが他のすべての点で優れているように見えるので、あまりにも悪いエラー受容はそれをしません。

DjangoコードにSentryを使用しますが、SentryがJavascriptでどのように機能するかについての情報を探しているときに、この問題に遭遇しました。 raven-jsの現在の実装では、すべてのJSエラーを明示的にキャッチしてSentryに報告するコードが必要ですか?

@adityar7そうではありません。 Raven.jsは、可能であれば、モンキーパッチを適用して物事を傍受するのが最善であることを試みます。 さらにいくつかのエッジケースでは、明示的にラップする必要があるかもしれませんが、私たちは物事が自動的に行われるように真剣に取り組んでいます。

@mattrobenoltいくつかの構文を修正することで機能するようになりました。 ありがとう!

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