.NET Framework - 例外設計原則の詳細な説明

Frontier

例外設計ガイドライン。Microsoft msdn を参照し、自分自身の理解と過去の開発における例外エラーの処理を組み合わせ、ソフトウェア開発アーキテクチャを要約し、一連の例外エラー ガイドラインをより適切に設計する方法を説明します。

ガイドラインの紹介

実行失敗の概念

実行失敗の意味: 実行失敗は、メンバーが意図した動作(メンバー名が示す内容)を実行できない場合に発生します。たとえば、OpenFileの場合です。メソッドは開いているファイル ハンドルを呼び出し元に返すことができないため、実行失敗とみなされます。

翻訳:

操作失敗の意味: メンバー モジュールが期待されたタスクを完了できない場合は、操作が失敗したと見なされます。 。たとえば、OpenFile メソッドは、開いているファイルのハンドルを呼び出し元に返すことができず、操作は失敗します。

フレームワークでの例外処理

フレームワークでは、実行エラーを含むすべてのエラー条件に例外が使用されます。

概要ガイドライン

例外を設計する際にどのような手法を禁止すべきか、どの手法を躊躇せずに行うべきか、どのような手法を考慮すべきかを以下の表に示します。

番号

メソッド練習リターンエラーコード禁止次のことをお勧めします検討禁止事項コントラクトの例外処理部分を考慮してください禁止9例外フィルターで例外をスローすることを検討してください。finally ブロックからの例外を明示的にスローする。

項目 4 の説明:

日常のコーディングでは、例外に関連するパフォーマンスの問題を回避するために、一般的なシナリオで例外をスローする可能性のあるメンバーの Tester-Doer パターンを考慮してください。Tester-Doer パターンは、例外をスローする可能性のある呼び出しを待ちます。例外を 2 つの部分に分割します: テスターと実行者。テスターは、実行者が例外をスローする原因となる可能性のある状態のテストを実行します。これにより、例外をスローするコードの直前にテストが挿入されます。 http://blog.csdn.net/troubleshooter/article/details/18401491 より

参考コード例:

Tester と Doer はそれぞれ役割を実行し、例外スローを完全に削減し、パフォーマンスを向上させます。
Doer: 上記の ステータス モニタリングは、DoProcess() によって処理される前は正常であり、それが false の場合、DoProcess() に DoCheck() ロジックが含まれている場合は例外がスローされますが、この分離の後、DoProcess( ) は例外をスローしません。

if(DoCheck()==true)//这是Tester:状态监测
    DoProcess();

ソフトウェア開発における一般的な例外と処理方法（独自のまとめ）

1 UI レイヤによって公開される操作インターフェースは try{}catch{} ブロックでラップすることが推奨されており、スローされる例外は次のようになりますcatch でディスクに書き込まれます。

2 UI レイヤーでタイマーが使用されている場合、

counter コールバック関数で例外が発生した後、エラー ログがファイルに書き込まれるのを防ぐためにタイマー を停止する必要があります。 3

4 throw は今後の操作を直接中断し、スタックの外側の層、try{} と catch{}、つまり UI 層にジャンプします。この特性を利用して、 一般に関数がエラーを返さないことが推奨されます。コード。

5 バッチインポートされたデータの処理中に、ローカル例外が発生しました。 Excel は、人員、設備、計画、資材、プロセスなどをインポートします。データの特定の行がルールに違反している場合、現時点では例外をスローすることはお勧めしません。例外がスローされると、そのデータは以降の行はインポートできず、インポートされたデータはダーティ データになります。 通常、2 つの方法があります。特定の行に不正なデータが表示された場合は、それをログ ファイルに記録し、後でこのファイルに基づいてどのデータがインポートされていないのかを確認し、これを個別に処理します。 インポートする前に、すべての行のデータを直接確認してください。合法かどうかにかかわらず、正しいことを確認した後、1つずつインポートしてください。

そうでない場合は、プロンプトが直接ポップアップ表示され、データはデータベースに書き込まれません。

一般的には後者のアプローチが推奨されます
。このアプローチは Tester-Doer 例外モードと呼ばれ、Microsoft も推奨しています。 6 ダッシュボード表示データの処理中にローカル例外が発生しました。この処理モードは5とは異なります。このとき例外が発生した場合、一般的には前者の5の方法が採用されることが多いです: 正しいデータが表示され、不正なデータはレビューのためにログに書き込まれます;また、表示されたインターフェイスでメイン データが存在しない場合、例外が直接スローされ、ログに書き込まれ、ログを通じて解決されることもあります。したがって、データの異常重大度に応じて処理する必要があります。

7 開発ドキュメント、ログ、分析に基づいて、特定の機能が実装されていない理由を見つけてみます。まず、開発ドキュメントを保管し、現在のユーザー要件が開発ドキュメントの要求と一致しているかどうかを確認します。一貫性がある場合、この時点でログの役割が表示されます。たとえば、1 週間以内のすべてのプロセスの完了を要約したグラフが表示されます。プロセス データがない場合は、その円グラフが存在しない可能性があります。開発プロセスにチェックが入っている場合、プロセスが存在するわけではありません。プロセスが見つからない場合は、ログにプロセスが書き込まれると、その理由が判明する可能性があります。したがって、この種の問題もログに記録する必要がありますが、エラーではありませんが、例外として分類される可能性があります。

8 この関数は、後続のロジックによってメソッドとプロパティが参照されるオブジェクトを返します。これは避けられない！そして、ほとんどの関数の実装はこれに依存します。返されたオブジェクトは後で参照されるため、null の場合は、UI レイヤーに渡されてメッセージ プロンプトが表示されるか、例外が直接スローされて UI レイヤーが処理するかに関係なく、null 比較を行うことをお勧めします。状況に応じて、それをログに書き込みます。

		1
	2	実行エラー、OpenFile() などの例外をスローします。ファイルハンドルが返されませんでした
	3	コードの実行を継続するのが安全でなくなった場合は、System.Environment.FailFast を呼び出してプロセスを終了するか、例外をスローするかを検討してください。
	4	可能であれば、通常の制御フローで例外をスローします。以下の分析を参照してください
	5	例外スローのパフォーマンスへの影響。
	7	例外を戻り値として返す
	8	例外ジェネレーターメソッドを使用して、コードの肥大化を回避し、ヘルパー メソッドを使用して例外とプロパティを作成します。

以上が.NET Framework - 例外設計原則の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。