2

エラーによってライブラリを使用しているサードパーティのページが壊れないように、javascript ライブラリ全体を try catch ブロック内にラップすることを考えています。

また、自分のコードによってスローされたエラーをキャッチして、サーバーに送信することもできます。

私の唯一の質問は、これを行うことで発生する可能性のある潜在的な負の副作用はありますか? (パフォーマンス、エラー追跡など)

4

3 に答える 3

3

ライブラリをtry{}ブロックにラップするのは得策ではありません。いくつかの異なる問題があります。特に、V8 は の内部でスタックを最適化できないため、try{}パフォーマンスが大幅に低下します。実際には想定していないものをthrowエラーにラップすることは、デバッグ コンソールからエラーを飲み込んで隠してしまうため、一般的には良い方法ではありません。

また、ライブラリをラップしても、try{} catch(e) {}発生するすべてのエラーを魔法のようにキャッチできるわけではありません。おそらく、「ライブラリ」は、ロード時に 1 回実行される JavaScript コードのチャンクにすぎませんが、try{}. これはキャッチしないことに注意することが重要です:

try {
    setTimeout(function() {
        throw "test";
    }, 100);
} catch(e) { 
    console.log( "I got caught" );
}

jsFiddle で試してみてください

幸いなことに、「処理されていない」エラーをキャッチするのに適した場所があります。window.onerror「ファースト パーティ」の開発者にとっては、正気を保つことはかなり良い考えですが、ライブラリに取り組んでいるときは、代わりに堅実な単体テストに頼る必要があります。「ファースト パーティの開発者」向けに、明確で使いやすいバグ報告フォームを用意することも必須です。私を信じてください、あなたのライブラリが壊れたら、人々は文句を言うでしょう。:)

PS -プログラマー SE でこの質問を見つけました。try{}

PPS - まともなjsperfを使用して見つけました。見てみると、ブロックtry{}を含む関数のパフォーマンスが低下することが示唆されているようです。try{}

于 2012-09-16T07:29:34.293 に答える
1

例外を飲み込んでいる場合、サードパーティのページが壊れるのを止めているわけではありません.コードが呼び出されて例外が発生しました.明らかにページは壊れています.サードパーティのページの開発者はそれを知らない.あなたのコードが壊れました。それは私見の大きな欠点です。何か悪いことが起こったら、善のために誰かに知らせてください。そのための例外です。

于 2012-09-16T02:55:27.863 に答える
0

私はBlenderに同意しますが、理想的には、徹底的なQAによってエラーを追跡しようとしますが、「マイナスの影響は何でしょうか」という質問に答えます。

  • パフォーマンスの観点から、エラーが発生しない場合、try-catchブロックは効果がありません。そして、これはコードのサイズに依存しません。try / catchは、エラーが発生した場合にのみオーバーヘッド効果があります。また、コードのサイズによって、このオーバーヘッドが大幅に増減することはありません。ほとんどの場合、エラー処理は、ブロック全体ではなく、キャッチされたブロックの戻りタイプを調べます（ECMA仕様の96ページを楽しんでください:)
  • @Aquinasには、他のサードパーティスクリプトがページが壊れている可能性があることを知る必要があるという良い点もあります...
于 2012-09-16T03:10:36.150 に答える