質問

いくつかの事前条件と事後条件を持つメソッドがあるとします。 達成されていない各前提条件に対して例外クラスを作成しても大丈夫ですか？ 例えば： pre1を達成しないということは、notPre1Exceptionインスタンスをスローすることを意味します。

役に立ちましたか？

解決

はい、いいえ。

はい-前提条件に違反することは、例外をスローする適切なタイミングです。より具体的な例外をスローすると、その特定の例外を簡単にキャッチできます。

いいえ-プログラム/ APIのすべての前提条件に対して新しい例外クラスを宣言するのは、やり過ぎのようです。これにより、最終的に数百または数千の例外が発生する可能性がありました。これは精神的にも計算上も無駄に思えます。

前提条件違反に対して例外をスローすることをお勧めします。ただし、各前提条件に新しい例外を定義することはお勧めしません。代わりに、特定の前提条件違反ではなく、特定のタイプの前提条件違反を対象とするより広範なクラスの例外を作成することをお勧めします。 （既存の例外を適切に使用することもお勧めします。）

他のヒント

なぜPreconditionFailedException（string precondition）を定義したくないのですか？失敗した前提条件ごとに異なる例外タイプをスローするのは過剰です。

失敗した前提条件は、AssertExceptionなどをスローする必要があります。メソッドを呼び出す前に、その前提条件を保持する必要があります。呼び出し元がこのチェックを行わない場合は、プログラムのバグか、メソッド（API）の誤った使用です。

前提条件を満たしていない場合にのみ、まれな例外が発生します。

私にとって例外の便利な使い方のように聞こえます。単一の「前提条件失敗」例外を設定して、失敗した前提条件を例外メッセージに入れることもできますが、一般的な「前提条件失敗」よりもきめ細かなロギングとデバッグが可能になります。

例外の使用と処理を計画している限り、すべての例外に別の例外を作成しても構いません。

エラー/例外処理が優れているほど、後の段階でソフトウェアをデバッグするのが簡単になることがわかりました。

例：すべての不正な入力を処理する汎用excpeitonがある場合、エラーがある場合はメソッドに渡されたすべてを調べる必要があります。すべてのタイプの悪い状態の例外をお持ちの場合は、どこを見ればよいかがわかります。

それは可能に見えますが、前提条件をこの方法で処理したい場合は、クラスメソッドごとにN個の例外クラスが作成されます。 「非機能的」クラスの爆発的な成長のように見えます。

「コア」機能が前提条件の違反を処理しないコードが好きでした（アサートすることは別として-とても助かります！）。その後、このコードを「前提条件チェッカー」にラップして、例外をスローするか、そうでなければ不満を通知します。

クラスを作成する必要があるかどうかを判断する非常に一般的な方法として（および例外はクラスです）、このクラスを他のすべてのクラスから一意にするコードがあるかどうかを判断する必要があります（この場合例外）。

そうでない場合は、例外に文字列を設定して1日だけ呼び出します。例外でコードを実行している場合（おそらく、exception.resolve（）または何かを呼び出すことで複数の状況を処理できる一般的な回復メカニズム）、それは役に立つかもしれません。

例外は常にこのルールに従うわけではないことを理解していますが、言語によって提供される例外にはビジネスロジックを含めることができないため、それは多かれ少なかれだと思います（ビジネスを知らないため、ライブラリは常にオブジェクト指向ルールの例外でいっぱいになる傾向があります）

ここでベンは目標を達成していると思います。例外をキャッチしない場合、異なる例外をスローする意味は何ですか？あなたが本当に別のものをスローしたい場合は、少なくとも共通の＆quot; PreconditionFailedException＆quot;があります。それらすべてが派生する基本クラスを作成し、それらを何らかの階層に編成して、それらのグループをキャッチできるようにします。個人的には、私は別のものを持っているわけではなく、それぞれの失敗の詳細とともにスローする一般的な例外があります。

いいえ、前提条件ごとに特定の例外を作成しないでください。これは、契約による設計の原則に反するためです。

前提条件の実装の結果は、それらがドキュメントの一部であり、呼び出し元がすべての前提条件が有効であることを確認するために必要なメソッドを提供する必要があるということです。 （つまり、メソッドの実行がオブジェクトのステータスに依存している場合、ステータスを確認するメソッドは呼び出し元が利用できるようにする必要があります。）

したがって、呼び出し元は、メソッドを呼び出す前にすべての前提条件が満たされているかどうかを確認できる必要があります。

違反した前提条件ごとに特定の例外を実装すると、呼び出し元はメソッド呼び出しの周りでtry / catchパターンを使用するようになります。これは、Design-by-Contractの哲学と矛盾しています。

チェックされていない例外（JavaのRuntimeExceptionのサブクラス）を作成する限り問題ありません。ただし、Javaでは、アサーションを使用することをお勧めします。

これを行う場合、それらがすべて別の一般的なカスタム例外を継承することを確認してください。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top