JavaScript Error をキャプチャして分析する方法_javascript のヒント

try {
localStorage.setItem( 'date' , Date.now());
} catch (error) {
reportError(error);

listeners.forEach(function(listener) {
try {
listener();
} catch (error) {
reportError(error);

window.onerror


try-catch でカバーされていない領域では、例外が発生した場合、window.onerror を通じてのみキャプチャできます。

reportError({
message: errorMessage,
script: scriptURI,
line: lineNumber
});
賢く、window.addEventListener または window.attachEvent を使用して window.onerror をリッスンしないように注意してください。多くのブラウザは window.onerror のみを実装するか、window.onerror の実装のみが標準です。ドラフト標準でも window.onerror が定義されていることを考慮すると、window.onerror をそのまま使用できます。
属性の損失

キャプチャされた例外を収集し、クエリと分析のためにサーバー側のストレージにバッチで送信するための reportError 関数があるとします。では、どのような情報を収集したいのでしょうか?さらに役立つ情報には、エラー タイプ (name)、エラー メッセージ (message)、スクリプト ファイル アドレス (script)、行番号 (line)、列番号 (column)、およびスタック トレース (stack) が含まれます。 try-catch を通じて例外がキャッチされた場合、この情報は Error オブジェクト (主流のブラウザでサポートされている) にあるため、reportError もこの情報を収集できます。しかし、window.onerror を通じてキャプチャされた場合、このイベント関数には 3 つのパラメーターしかないことがわかります。そのため、これら 3 つのパラメーター以外の情報は失われます。
シリアル化されたメッセージ

Error オブジェクトが自分で作成された場合、error.message は自分で制御されます。基本的に、error.message に何を入力しても、window.onerror の最初のパラメータ (メッセージ) になります。 (ブラウザーは実際には、「Uncaught Error: 」プレフィックスを追加するなど、わずかな変更を加えます。) したがって、必要なプロパティ (JSON.Stringify など) をシリアル化し、それらを error.message に保存してから読み取ることができます。 in window.onerror それを取り出して逆シリアル化するだけです。もちろん、これは自分で作成した Error オブジェクトに限定されます。
5 番目のパラメータ

ブラウザの製造元も、window.onerror を使用するときに誰もが直面する制限を認識しているため、window.onerror に新しいパラメータを追加し始めました。行番号のみで列番号がまったく対称的ではないように見えることを考慮して、IE はまず列番号を追加し、それを 4 番目のパラメーターに入れます。しかし、誰もが完全なスタックを取得できるかどうかのほうを心配しているため、Firefox はスタックを 5 番目のパラメータに入れる方がよいと述べています。しかし、Chrome は、Error オブジェクト全体を 5 番目のパラメータに入れる方がよいと述べています。カスタム プロパティを含め、必要なプロパティを読み取ることができます。その結果、Chrome はより高速に動作し、Chrome 30 に新しい window.onerror シグネチャが実装され、それに応じて標準ドラフトが作成されることになりました。
このステップ 1、ステップ 2、ステップ 3 がある場合は、誰もが知っています。依存関係がある場合は、この順序に厳密に従う必要があります。そうしないと、エラーが発生する可能性があります。ブラウザは step1 と step3 のファイルを並行してリクエストできますが、実行中の順序は保証されます。 XMLHttpRequest を通じて step1 と step3 のファイルの内容を自分で取得する場合は、それらの順序が正しいことを確認する必要があります。さらに、ステップ 2 を忘れないでください。ステップ 2 は、ステップ 1 が非ブロック方式でダウンロードされるときに実行できるため、ステップ 2 に手動で介入して、ステップ 1 が完了するまで待機させてから実行する必要があります。

Web サイト上のさまざまなページに <script> タグを生成するためのツール セットがすでにある場合は、このツール セットを調整して <script> タグを変更する必要があります。 <br><br><div class="codetitle"> <span>コードをコピーします<a style="CURSOR: pointer" data="91019" class="copybut" id="copybut91019" onclick="doCopy('code91019')"><u></u> コードは次のとおりです。</a></span> </div><script<div class="codebody" id="code91019">scheduleRemoteScript('http: //cdn.com/step1.js'); <br></script>
scheduleInlineScript(関数 step2() {})() ;
});
<script> <br>scheduleRemoteScript('http://cdn.com/step3.js'); <br><br><br>scheduleRemoteScript とscheduleInlineScript という 2 つの関数を実装し、外部スクリプト ファイルを参照する最初の <script> タグの前にこれらの関数が定義されていることを確認する必要があります。その後、残りの <script> タグが上記のように書き換えられます。形状。元々すぐに実行された step2 関数が、より大きなコード関数に配置されていることに注意してください。コード関数は実行されません。これは単なるコンテナであるため、ステップ 2 の元のコードはエスケープせずに保持できますが、すぐには実行されません。 <br><br>次に、アドレスに基づいてscheduleRemoteScriptによってダウンロードされたファイルコンテンツと、scheduleInlineScriptによって直接取得されたコードが正しい順序で次々に実行できることを保証する完全なメカニズムを実装する必要があります。詳細なコードはここでは説明しませんので、興味があればご自身で実装してください。 <br>行番号逆チェック <br><br>CORS を通じてコン​​テンツを取得し、ページにコードを挿入すると、セキュリティ制限を突破できますが、行番号の競合という新たな問題が発生します。もともと、error.script は一意のスクリプト ファイルを見つけるために使用でき、error.line は一意の行番号を見つけるために使用できました。さて、これらはすべてページに埋め込まれたコードであるため、error.script では複数の <script> タグを区別することはできません。そのため、各 <script> タグ内の行番号は 1 から始まります。エラーが発生したソース コードの場所を特定するために使用されます。 <br><br>行番号の競合を避けるために、各 <script> タグ内の実際のコードで使用される行番号の範囲が互いに重ならないように、一部の行番号を無駄にすることができます。たとえば、各 <script> タグの実際のコードが 1000 行以下であると仮定すると、最初の <script> タグのコードを 1 ～ 1000 行とし、2 番目のコードを<script> タグは 1001 ～ 2000 行目 (その前に 1000 行の空白行を挿入) を占め、3 番目の <script> タグ内のコードは 2001 ～ 3000 行目 (その前に 2000 行の空白行を挿入) を占めます。次に、data-* 属性を使用してこの情報を記録し、簡単に取得できるようにします。 <BR><div class="codetitle"><span><a style="CURSOR: pointer" data="17722" class="copybut" id="copybut17722" onclick="doCopy('code17722')"><U>コードをコピー コードは次のとおりです:</script>

>< script data-line-start="1001">
// 'n' * 1000
// ステップ 2 のコード
>data-src="http://cdn.com/step3.js"
data-line-start="2001"
>
// 'n' * 2000
//ステップ 3 のコード



この処理の後、エラーの error.line が 3005 であれば、実際の error.script は「http://cdn.com/step3.js」である必要があり、実際の error.line はそれです5である必要があります。この行番号の逆チェックは、前述した reportError 関数で完了できます。

もちろん、各スクリプト ファイルの行数が 1000 行のみであることは保証できず、一部のスクリプト ファイルは 1000 行より大幅に少ない場合があるため、各

に 1000 行の固定範囲を割り当てる必要はありません。スクリプト>タグ。各 <script> タグで使用される間隔が重複しない限り、実際のスクリプト行数に基づいて間隔を割り当てることができます。 <br>crossorigin 属性 <br><br>さまざまなソースからのコンテンツに対するブラウザのセキュリティ制限は、もちろん <script> タグに限定されません。 XMLHttpRequest は CORS を通じてこの制限を突破できるのに、なぜタグを通じてリソースを直接参照できないのでしょうか?もちろんこれは可能です。 <br><br>異なるソース スクリプト ファイルを参照する <script> タグの制限は、異なるソース イメージ ファイルを参照する <img> タグにも適用されます。 <img> タグが別のソースからのものである場合、それが <canvas> 描画で使用されると、<canvas> は書き込み専用になり、Web サイトが JavaScript を通じて不正な画像データを盗むことができなくなります。その後、<img> タグは、crossorigin 属性を導入することでこの問題を解決しました。 crossorigin="anonymous" を使用した場合は匿名 CORS と同等であり、「crossorigin="use-credentials"」を使用した場合は認証付きの CORS と同等です。 <BR><br><img> タグでこれができるのに、なぜ <script> タグではできないのでしょうか?そこでブラウザの製造元は、上記のセキュリティ制限を解決するために、同じcrossorigin属性を<script>タグに追加しました。 Chrome と Firefox は現在、この属性を問題なくサポートしています。その結果、サーバーが匿名 CORS のみをサポートしている場合、Safari は認証が失敗したものとして扱います。 CDN サーバーはパフォーマンス上の理由から静的コンテンツのみを返すように設計されているため、リクエストに基づいて CORS 認証に必要な HTTP ヘッダーを動的に返すことはできません。Safari はこの機能を使用して上記の問題を解決できません。 <br>概要 <BR><🎜>JavaScript の例外処理は他の言語と何ら変わらない非常に単純なように見えますが、すべての例外を実際にキャッチして属性を分析するのはそれほど簡単ではありません。 JavaScript 例外をキャプチャする Google Analytics のようなサービスを提供するサードパーティ サービスがいくつかありますが、詳細と原則を理解したい場合は、やはり自分で行う必要があります。 <🎜></script>