Frontline

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

ガイドラインの紹介

実行失敗の概念

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

翻訳:

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

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

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

概要ガイドライン

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

項目 4 の説明:

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

より 参考コード例:

Tester と Doer はそれぞれ役割を実行し、例外スローを完全に減らし、パフォーマンスを向上させます。
Doer: 上記のステータス監視が良好であれば DoProcess() で処理でき、 false であれば DoProcess() に DoCheck() ロジックが含まれている場合は例外がスローされますが、この分離後は DoProcess()例外はスローされません!

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

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

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

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

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

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

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

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

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