exception - ドメイン クラスで例外に対してアサーションを使用する場合

Question

ドメインクラス内で例外処理の代わりにアサーションを使用する状況はありますか...

Answer 1

クラスのユーザーがクラスを意図したとおりに使用していることを確認する、パラメーターの検証やその他のチェックに例外を使用します。

内部整合性チェックにアサーションを使用します。つまり、クラスのユーザーではなく、失敗したことを示します。

したがって、クラスのユーザーがアサーションの失敗に気付いた場合、それは (おそらく) コードの使用ではなく、コードの内部エラーであることがわかります。一方、get パラメータの検証で例外が発生した場合は、それが自分の責任であることを認識しています。

Answer 2

一度もない。アサーションは、エラー処理の有効な形式ではありません。これらを使用して、テスト中にプログラム エラーを特定するのに役立ててください。

Answer 3

アサーションは、アプリケーションが何らかの理由で実行を継続できない、決して発生してはならない予期されていない状態を反映します。一方、例外は、「正常」とは見なされないが、予期しないものではなかった状態を示します。回復できるかもしれません。

例として、ヒープにスペースを割り当て、この割り当てが失敗した場合、作業を続行できないため、返されたアドレスが有効であると断言します。無効な場合、アサーションは失敗し、プログラムは失敗します。

一方、読み取り用にファイルを開いて、そのファイルが存在しない場合は、状況から回復できる可能性があります。その場合、例外がスローされます (キャッチされ、可能な限り処理されます)。

一般に、アサーションはデバッグ段階で最も役立ちますが、例外は通常のプログラム フローとエラー処理の一部と見なされます。一般的なコンセンサスは、(明らかなクラッシュからユーザーを保護するために) 製品コードではアサーションを無効にする必要があるというものですが、これは非生産的であり、ユーザーはアサーションの失敗を確認する必要があると主張する学派を読んだことがあります。問題を適切に報告できます。

個人的には、2 つの手法を組み合わせることもあります。通常、スローされる可能性がないと思われる例外をキャッチしている場合。上記の例では、ファイルを開こうとする前にファイルの存在を確認した場合、例外がスローされるとは考えていません。例外がスローされた場合は、関連する catch ブロックでアサーションを発生させることでこれに対処する傾向があります。これは、そのような例外が完全にチェックされる Java では特に便利な手法だと思います。