アプリケーションが予期しないすべての条件に対して例外を作成しました。UserNameNotValidExceptionなどPasswordNotCorrectException。
しかし、これらの条件に対して例外を作成してはいけないと言われました。私の UML では、それらはメイン フローの例外です。では、なぜ例外にならないのでしょうか?
例外を作成するためのガイダンスやベストプラクティスはありますか?
ベストアンサー1
私の個人的なガイドラインは、現在のコード ブロックの基本的な仮定が誤りであることが判明した場合に例外がスローされるというものです。
例 1: 任意のクラスを調べて、そのクラスが List<> から継承されている場合に true を返す関数があるとします。この関数は、「このオブジェクトは List の子孫ですか?」という質問をします。この関数は例外をスローすることはありません。その動作にはグレーゾーンがないため、すべてのクラスは List<> から継承するか、継承しないかのいずれかであるため、答えは常に「はい」または「いいえ」になります。
例 2: List<> を調べて、長さが 50 を超える場合は true を返し、長さが 50 未満の場合は false を返す別の関数があるとします。この関数は、「このリストには 50 を超える項目がありますか?」という質問をします。ただし、この質問は仮定に基づいています。つまり、渡されたオブジェクトがリストであると想定しています。NULL を渡すと、その仮定は false になります。その場合、関数がtrue またはfalseを返すと、関数自体のルールに違反することになります。関数は何も返せず、質問に正しく回答したと主張することはできません。そのため、関数は返さず、例外をスローします。
これは、「誘導尋問」論理的誤り。すべての関数は質問をします。与えられた入力がその質問を誤りにする場合は、例外をスローします。void を返す関数ではこの線を引くのが難しくなりますが、肝心なのは、関数の入力に関する想定に違反した場合、通常どおりに戻るのではなく、例外をスローする必要があるということです。
この方程式の反対側は、関数が頻繁に例外をスローしていることがわかった場合は、おそらくその関数の仮定を改良する必要があるということです。