例外処理のベストプラクティスまたは推奨事項 [閉まっている]

私のプログラムの主な問題は、コード構造/組織とエラー処理の2つだと思います。Code Complete 2を読んでいますが、潜在的な問題を扱うために読むものが必要です。

たとえば、Webサイトで、ユーザーがjavascriptを介してデータを改ざんした場合にのみ何かが発生する可能性がある場合、そのことについて記述しますか？また、いつエラーをキャッチしませんか？入力として文字列とintを期待するクラスを作成し、それらが文字列とintではない場合、それを確認しますか、それとも間違ったパラメーターを渡した呼び出しメソッドにバブルさせますか？

これはここでの単一の回答では答えられない広範なトピックであることを知っているので、私が探しているのは、適切な例外処理の実践を教えるとして一般に受け入れられている本またはリソースです。

覚えておくと良いことの1つは、例外処理を実行することですwhen there is a need。

.NET開発プラットフォームの場合、MSDNガイドライン- 例外処理のベストプラクティスに従うだけでなく、この素敵なコードプロジェクトの記事-.NETでの例外処理のベストプラクティスも確認してください。

ただし、次のガイドラインは、ほとんどの開発プラットフォームに当てはまります。

• 例外を使用してビジネスロジックを管理しないでください。代わりに条件ステートメントを使用してください。if-elseステートメントを使用して制御を明確に行うことができる場合は、例外を使用しないでください。読みやすさとパフォーマンスが低下するためです（null制御、ゼロ除算など）。。

• 例外名は明確で意味のあるものにし、例外の原因を明記する必要があります。

• メソッドの実装中にエラー条件の例外をスローします。たとえば、FileNotFoundExceptionの代わりに-1、-2、-3などの値を返す場合、そのメソッドは理解できません。

• 最上位の例外クラスの代わりに特定の例外をキャッチします。これにより、パフォーマンス、可読性、およびより具体的な例外処理が追加されます。

• 条件付きのNullコントロールは、NullPointerExceptionをキャッチする代わりになりません。メソッドがnullを返す可能性がある場合は、if-elseステートメントで制御します。戻り値がNullPointerExceptionをスローする可能性がある場合は、キャッチします。

• 価格のために例外を再スローしないようにしてください。再スローが必須だった場合は、新しい例外を作成する代わりに同じ例外を再スローしてください。これにより、パフォーマンスが向上します。各レイヤーの追加情報をその例外に追加できます。

• 現在のExceptionクラス（UserException、SystemExceptionおよびそれらのサブタイプなど）を拡張して独自の例外階層を定義し、それらを使用します。これを行うことにより、例外を特殊化し、例外の再利用可能なモジュール/レイヤーを定義できます。このリンクでフォローする詳細