language-agnostic - 前提条件と例外

Question

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

score 10 · Accepted Answer

PreconditionFailedException(string precondition) を定義したくないのはなぜですか? 失敗した前提条件ごとに異なる例外タイプをスローするのはやり過ぎです。

score 4 · Accepted Answer

はいといいえ。

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

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

前提条件違反に対して例外をスローすることをお勧めします。ただし、前提条件ごとに新しい例外を定義することはお勧めしません。代わりに、特定の前提条件違反ではなく、特定の種類の前提条件違反をカバーする、より広範な例外クラスを作成することをお勧めします。(既存の例外が適している場合は、それを使用することもお勧めします。)

score 2 · Accepted Answer

失敗した前提条件は、AssertException などをスローする必要があります。メソッドを呼び出す前に、前提条件が満たされている必要があります。呼び出し元がこのチェックを行わない場合、それはプログラムのバグか、メソッド (API) の不適切な使用です。

score 1 · Accepted Answer

いいえ、前提条件ごとに特定の例外を作成しないでください。これは、Design-by-Contract の原則に反するためです。

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

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

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

score 1 · Accepted Answer

1

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

于 2008-09-29T18:02:02.630 に答える

score 1 · Accepted Answer

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

score 1 · Accepted Answer

それらを使用して処理することを計画している限り、すべての例外に対して別の例外を作成しても問題ないと思います。

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

例: すべての不正な入力を処理する一般的な例外がある場合、エラーが発生した場合、メソッドに渡されたすべてのものを調べる必要があります。すべてのタイプの悪い状態の例外があれば、どこを見ればよいか正確にわかります。

score 1 · Accepted Answer

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

私はいつも、「コア」機能が前提条件の違反を処理しないコードが好きでした (前提条件をアサートすることは別として - とても助かりました!)。このコードは、「事前条件チェッカー」でラップできます。これは、例外をスローするか、そうでない場合は不満足を通知します。

score 1 · Accepted Answer

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

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

例外が常にこのルールに従うとは限らないことは認識していますが、言語によって提供される例外にはビジネスロジックを含めることができないため、多かれ少なかれそうなると思います（ビジネスを知らないため、ライブラリは常にそうなる傾向があります）。 OO 規則の例外がいっぱい)

score 1 · Accepted Answer

ベンはここで的を射ていると思います。それらをキャッチするつもりがない場合、さまざまな例外をスローする意味は何ですか? 本当に別のものをスローしたい場合は、少なくともそれらすべてが派生する共通の「PreconditionFailedException」基本クラスを持ち、それらを何らかの階層に編成して、それらのグループをキャッチできるようにします。個人的には、私は異なるものを持っていません。それぞれの失敗の詳細をスローする共通の例外があります。

score 0 · Accepted Answer

チェックされていない例外（JavaのRuntimeExceptionのサブクラス）にする限り、大丈夫だと思います。ただし、Java ではアサーションのみを使用することをお勧めします。

score 0 · Accepted Answer

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

language-agnostic - 前提条件と例外

12 に答える 12

Related

Reference