メソッドが入力をチェックし、不正な入力を検出した場合、何をすべきか: 例外を発生させる (または別のエラーメカニズムを使用する) か、何もしない/間違った入力を無視するか?
Java では、パラメーターとして null 参照が指定されている場合、HashTable クラスは NullPointerException をスローします。これは面倒なこともありますが、エラーが早期に検出されるため、利点があると思います。他のメソッドの中には、不正な入力を無視して何もしないものがあります。それは煩わしさが少なく、通常は何も悪いことは起こりませんが、場合によっては、この動作が頭痛の種になることがありますか?
どちらの方法が良いかわかりません。だから私はあなたに尋ねます：この質問についてどう思いますか？
必ず例外をスローします。例外は、それらについて何かを強制するために意図的に迷惑です。
このように考えてみてください。プログラムが不正な入力に対して何もしない場合、何も起こらなかったこととその理由をユーザーにどのように知らせるべきでしょうか? また、エラー状態で何もしないプログラムをデバッグするのにどれくらいの時間がかかりますか?
それはあなたが取り組んでいる抽象化の文脈や層に依存すると思います。最も重要なことは一貫性を保つことです。そのレベルで例外をスローする場合は、先に進んで例外もスローします。そうでない場合は、レイヤーがどのように動作しているかを確認し、同じようにします。
これがパブリック メソッドであると仮定すると、メソッドとこのメソッドを呼び出すメソッドとの間のコントラクトは何ですか?
このメソッドを作成している場合、コントラクトは設計の一部です。選択できます
最終的には、メソッドが何を行っているか、およびメソッドにどのような期待を持っているかによって異なります。
クラスをメソッドに置き換えて、同じオプションを使用できます。
場合によっては、例外を発生させることができない場合があります (つまり、ファームウェアが組み込まれたマイクロコントローラー)。そのような場合、誤った入力を処理し、有効な入力を処理し続けるように設計されたプロセスが必要です。
乾杯、
-R
これは、開発しているアプリケーションに大きく依存します。
違法な入力にもかかわらず兵士を動かすことは、プログラムの出力が正しくないことを意味する場合があります。これは、薬の投与量を計算するアプリケーションにとって非常に悪いことです。一方、壊滅的な結果がなければ、おそらく何もしなくても問題ありません。
もう 1 つのオプションは、不正な入力を最も近い正当な値に変更することです (たとえば、整数の範囲が 0 ～ 100 で、-10 を受け取った場合、それを 0 に設定して処理を続行しても問題ない場合があります)。
作成している特定のメソッドでエラーをどのように処理するか、およびエラー処理がアプリケーション全体にどのように影響するかについて、考えられる結果について考えてみてください。
Fail Fast : 間違った入力を決して無視しません。問題を隠して、見つけにくくすることができます。
Design by Contract (DBC)を使用してこれを推進する人もいます。
プロジェクトや会社ですでに使用されているプラクティスに従うか、今すぐ定義してください。