JavaScript例外処理の詳細解説_JavaScriptスキル
フロントエンド エンジニアは皆、JavaScript に基本的な例外処理機能があることを知っています。 new Error() をスローすることができ、API の呼び出し時にエラーが発生した場合、ブラウザーも例外をスローします。しかし、ほとんどのフロントエンド エンジニアは、このような異常な情報を収集することを考えたこともないと推定されています
とにかく、更新後に JavaScript エラーが再発しない限り、ユーザーは更新することで問題を解決でき、ブラウザはクラッシュしません。この仮定は、シングル ページ アプリが普及する前から当てはまっていました。現在のシングル ページ アプリのステータスは、一定期間実行すると非常に複雑になります。ユーザーは、ここに到達するまでにいくつかの入力操作を実行した可能性があります。更新される必要があるかどうか。前回の操作を完全にやり直すべきではないでしょうか?したがって、これらの例外情報を取得して分析する必要があります。その後、ユーザー エクスペリエンスへの影響を避けるためにコードを変更できます。
例外をキャッチする方法
私たちは独自の throw new Error() を書きました。もちろん、 throw がどこに書かれているかを正確に知っているので、必要に応じてそれをキャッチすることができます。ただし、ブラウザ API を呼び出すときに発生する例外は、必ずしもキャッチするのが簡単ではありません。一部の API は例外をスローするように標準で記述されており、実装の違いや欠陥により個々のブラウザによってのみスローされる API もあります。前者の場合は、try-catch を通じてキャッチすることもできます。後者の場合は、グローバル例外をリッスンしてキャッチする必要があります。
トライキャッチ
一部のブラウザ API が例外をスローすることがわかっている場合は、プログラム全体がエラーによって不正な状態にならないように、呼び出しを try-catch に入れる必要があります。たとえば、window.localStorage は、データの書き込みが容量制限を超えると例外をスローします。これは、Safari のプライベート ブラウジング モードにも当てはまります。
{
を試してください localStorage.setItem('date', Date.now());
} キャッチ (エラー) {
reportError(エラー);
}
try-catch のもう 1 つの一般的な使用例はコールバックです。コールバック関数のコードは私たちの制御の範囲外であるため、コードの品質や、例外をスローする他の API が呼び出されるかどうかについてはわかりません。コールバックを呼び出した後の他のコードがコールバック エラーによって実行できなくなるのを防ぐために、呼び出しを try-catch に戻す必要があります。
listeners.forEach(function(listener) {
{
を試してください リスナー();
} キャッチ (エラー) {
reportError(エラー);
}
});
window.onerror
try-catch でカバーされていない領域では、例外が発生した場合、window.onerror を通じてのみキャッチできます。
window.onerror =
function(errorMessage, scriptURI, lineNumber) {
reportError({
メッセージ: errorMessage、
スクリプト: scriptURI、
行: 行番号
});
}
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 シグネチャが実装され、それに応じて標準ドラフトが作成されることになりました。
window.onerror = function(
エラーメッセージ、
scriptURI、
行番号、
列番号、
エラー
) {
if (エラー) {
reportError(エラー);
} else {
reportError({
メッセージ: errorMessage、
スクリプト: scriptURI、
行: 行番号、
列: 列番号
});
}
}
属性の正規化
前に説明したエラー オブジェクトの属性の名前は Chrome の命名方法に基づいています。ただし、ブラウザによってエラー オブジェクトの属性の名前は異なります。たとえば、スクリプト ファイルのアドレスは Chrome ではスクリプトと呼ばれますが、Firefox ではファイル名と呼ばれます。 。したがって、Error オブジェクトを正規化する、つまり、さまざまな属性名を統一された属性名にマップするための特別な関数も必要です。具体的な方法については、こちらの記事をご覧ください。ブラウザの実装は更新されますが、このようなマッピング テーブルを手動で維持することはそれほど難しくありません。
スタック トレース形式に似ています。この属性は、例外情報のスタックをプレーン テキスト形式で保存します。各ブラウザで使用されるテキスト形式が異なるため、プレーン テキストから各フレームの機能を抽出するための正規表現を手動で管理する必要もあります。識別子)、ファイル(スクリプト)、行番号(line)、列番号(column)。
セキュリティ制限
「スクリプト エラー。」というメッセージが表示されるエラーが発生したことがある場合は、これが実際には、異なる作成元のスクリプト ファイルに対するブラウザの制限であることがおわかりいただけるでしょう。このセキュリティ制限の理由は次のとおりです。ユーザーがログインした後にオンライン銀行から返される HTML が匿名ユーザーに表示される HTML と異なると仮定すると、サードパーティの Web サイトはオンライン銀行の URI をスクリプトに組み込むことができます。 src 属性。もちろん、HTML は JS として解析できないため、ブラウザは例外をスローし、サードパーティ Web サイトは例外の場所を解析することでユーザーがログインしているかどうかを判断できます。このため、ブラウザーは、「スクリプト エラー」のような未変更のメッセージが 1 つだけ残り、他のすべての属性が消えるまで、さまざまなソースからのスクリプト ファイルによってスローされたすべての例外をフィルター処理します。
一定規模の Web サイトでは、スクリプト ファイルが異なるソースを持つ CDN に配置されるのが通常です。独自の小規模な Web サイトを構築する場合でも、jQuery や Backbone などの一般的なフレームワークがパブリック CDN 上のバージョンを直接参照して、ユーザーのダウンロードを高速化できるようになりました。したがって、このセキュリティ制限は何らかの問題を引き起こし、Chrome と Firefox から収集した例外情報が役に立たない「スクリプト エラー」になってしまいます。
CORS
この制限を回避するには、スクリプト ファイルとページ自体のオリジンが同じであることを確認してください。しかし、CDN によって高速化されていないサーバーにスクリプト ファイルを置くと、ユーザーのダウンロード速度は遅くなりませんか? 1 つの解決策は、スクリプト ファイルを CDN に配置し続け、XMLHttpRequest を使用して CORS 経由でコンテンツをダウンロードし、それをページに挿入するための <script> タグを作成することです。ページに埋め込まれているコードは、もちろん同じソースからのものです。 </p>
<p>これは簡単そうに見えますが、実装するには詳細がたくさんあります。簡単な例を使用すると: </p>
<p></p>
<div class="codetitle">
<span><a style="CURSOR: pointer" data="85881" class="copybut" id="copybut85881" onclick="doCopy('code85881')"><u>コードをコピーします</u></a></span> コードは次のとおりです:</div>
<div class="codebody" id="code85881">
<br>
<スクリプト src="<a href="http://cdn.com/step1.js"></script">http://cdn.com/step1.js"></script</a>><br>
<スクリプト><br>
(関数 step2() {})();<br>
</script>
<スクリプト src="http://cdn.com/step3.js">>
step1、step2、step3 の間に依存関係がある場合、厳密にこの順序で実行する必要があることは誰もが知っています。そうしないとエラーが発生する可能性があります。ブラウザは step1 と step3 のファイルを並行してリクエストできますが、実行中の順序は保証されます。 XMLHttpRequest を通じて step1 と step3 のファイルの内容を自分で取得する場合は、それらの順序が正しいことを確認する必要があります。さらに、ステップ 2 を忘れないでください。ステップ 2 は、ステップ 1 が非ブロック方式でダウンロードされるときに実行できるため、ステップ 2 に手動で介入して、ステップ 1 が完了するまで待機させてから実行する必要があります。
Web サイト上のさまざまなページに <script> タグを生成するためのツール セットがすでにある場合は、このツール セットを調整して <script> タグを変更する必要があります。
</p>
<p></p>
<div class="codetitle"><span><a style="CURSOR: pointer" data="68128" class="copybut" id="copybut68128" onclick="doCopy('code68128')">コードをコピーします<u></u></a> コードは次のとおりです:</span></div>
<div class="codebody" id="code68128">
<スクリプト><br>
スケジュールリモートスクリプト('http://cdn.com/step1.js');<br>
</script>
<スクリプト>
scheduleInlineScript(関数コード() {
(関数 step2() {})();
});
<スクリプト>
スケジュールリモートスクリプト('http://cdn.com/step3.js');
2 つの関数、scheduleRemoteScript と、scheduleInlineScript を実装し、外部スクリプト ファイルを参照する最初の <script> タグが定義されるようにする必要があります。その後、残りの <script> タグが上記の形式に書き換えられます。元々すぐに実行された step2 関数が、より大きなコード関数に配置されていることに注意してください。コード関数は実行されません。これは単なるコンテナであるため、ステップ 2 の元のコードはエスケープせずに保持できますが、すぐには実行されません。
<p>次に、アドレスに基づいてscheduleRemoteScriptによってダウンロードされたファイルコンテンツと、scheduleInlineScriptによって直接取得されたコードが正しい順序で次々に実行できることを保証する完全なメカニズムを実装する必要があります。詳細なコードはここでは説明しませんので、興味があればご自身で実装してください。 </p>
<p><strong>行番号の反転チェック</strong></p>
<p>CORS を通じてコンテンツを取得し、ページにコードを挿入すると、セキュリティ制限を突破できますが、行番号の競合という新たな問題が発生します。もともと、error.script は一意のスクリプト ファイルを見つけるために使用でき、error.line は一意の行番号を見つけるために使用できました。さて、これらはすべてページに埋め込まれたコードであるため、error.script では複数の <script> タグを区別することはできません。そのため、各 <script> タグ内の行番号は 1 から始まります。エラーが発生したソース コードの場所を特定するために使用されます。 </p>
<p>行番号の競合を避けるために、各 <script> タグ内の実際のコードで使用される行番号の範囲が互いに重ならないように、一部の行番号を無駄にすることができます。たとえば、各 <script> タグの実際のコードが 1000 行以下であると仮定すると、最初の <script> タグのコードを 1 ~ 1000 行とし、2 番目のコードを<script> タグは 1001 ~ 2000 行目 (その前に 1000 行の空白行を挿入) を占め、3 番目の <script> タグ内のコードは 2001 ~ 3000 行目 (その前に 2000 行の空白行を挿入) を占めます。次に、data-* 属性を使用してこの情報を記録し、簡単に取得できるようにします。 </script>
<スクリプト
data-src="http://cdn.com/step1.js"
データライン開始 = "1"
>
// ステップ 1 のコード
<スクリプト
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 行より大幅に少ない場合があるため、各 <script> タグに 1000 行という固定範囲を割り当てる必要はありません。 。各 <script> タグで使用される間隔が重複しない限り、実際のスクリプト行数に基づいて間隔を割り当てることができます。 </script>
クロスオリジン属性
さまざまなソースからのコンテンツに対してブラウザーによって課されるセキュリティ制限は、もちろん

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









C++ での関数例外処理は、マルチスレッド環境でスレッドの安全性とデータの整合性を確保するために特に重要です。 try-catch ステートメントを使用すると、特定の種類の例外が発生したときにそれをキャッチして処理し、プログラムのクラッシュやデータの破損を防ぐことができます。

再帰呼び出しでの例外処理: 再帰の深さの制限: スタック オーバーフローの防止。例外処理を使用する: try-catch ステートメントを使用して例外を処理します。末尾再帰の最適化: スタックのオーバーフローを回避します。

C++ 例外処理を使用すると、例外をスローし、try-catch ブロックを使用して例外をキャッチすることで実行時エラーを処理するカスタム エラー処理ルーチンを作成できます。 1. 例外クラスから派生したカスタム例外クラスを作成し、what() メソッドをオーバーライドします。 2. throw キーワードを使用して例外をスローし、例外のタイプを指定します。扱った。

C++ ラムダ式の例外処理には独自のスコープがなく、デフォルトでは例外はキャッチされません。例外をキャッチするには、ラムダ式キャッチ構文を使用できます。これにより、ラムダ式がその定義スコープ内の変数をキャプチャできるようになり、try-catch ブロックで例外処理が可能になります。

マルチスレッド C++ では、例外処理は適時性、スレッドの安全性、明確性という原則に従います。実際には、ミューテックスまたはアトミック変数を使用することで、例外処理コードのスレッド セーフを確保できます。さらに、例外処理コードの再入性、パフォーマンス、テストを考慮して、コードがマルチスレッド環境で安全かつ効率的に実行されることを確認してください。

PHP 例外処理: 例外追跡を通じてシステムの動作を理解する 例外は、PHP がエラーを処理するために使用するメカニズムであり、例外は例外ハンドラーによって処理されます。例外クラス Exception は一般的な例外を表し、Throwable クラスはすべての例外を表します。 throw キーワードを使用して例外をスローし、try...catch ステートメントを使用して例外ハンドラーを定義します。実際のケースでは、例外処理を使用して、calculate() 関数によってスローされる DivisionByZeroError をキャプチャして処理し、エラー発生時にアプリケーションが適切に失敗できるようにします。

PHPでは、Try、Catch、最後にキーワードをスローすることにより、例外処理が達成されます。 1)TRYブロックは、例外をスローする可能性のあるコードを囲みます。 2)キャッチブロックは例外を処理します。 3)最後にブロックは、コードが常に実行されることを保証します。 4)スローは、例外を手動でスローするために使用されます。これらのメカニズムは、コードの堅牢性と保守性を向上させるのに役立ちます。

C++ で例外処理のパフォーマンスを最適化するには、次の 4 つの手法を実装できます。 不必要な例外スローを回避します。軽量の例外クラスを使用します。効率を優先し、必要な情報のみを含む例外クラスを設計します。コンパイラ オプションを活用して、パフォーマンスと安定性の最適なバランスを実現します。
