アサーションが通常デプロイメントで使用されないのはなぜですか?パブリックメソッドの引数をアサートすることは不適切であると調査しましたが、デプロイメントではプライベートメソッドの引数をアサートすることが適切です。なぜですか?
3 に答える
アサーションはデフォルトでは有効になっていません。有効にするには、-ea
パラメータをJVMに渡す必要があります。そのため、多くの場合、展開の単純な省略である可能性があります。その他の理由としては、パフォーマンス(アサートによって実行が著しく遅くなるという証拠はありません)、または適切なエラー処理が考えられます。つまり、本番システムがAssertionError
ライブをスローするのは不適切と見なされる場合があります。
プライベートメソッドの引数をアサートすることは、それらに渡される引数を完全に制御できることになっているため、適切です。パブリックメソッドOTOHは外部から呼び出されるため、渡される具体的な引数を制御できない可能性があります。したがって、明示的な引数チェックを実行し、無効な引数を適切に処理することをお勧めします(たとえば、などの適切なランタイム例外をスローすることによってIllegalArgumentException
)。 null参照の場合、JVMに。をスローさせますNullPointerException
。
アサーションはデフォルトで無効になっています。これは、バグを見つけるのに非常に役立つため、オーバーヘッドによって開発環境でのみ受け入れられるためです。すべてのパブリックメソッドでは、有効になっているアサーション(-ea JVMオプション)に依存せずに、とにかく入力をチェックする必要があります。そのため、それらは役に立たない(または存在しないはずです)のです。
一方、プライベートメソッドの場合は、すべてのメソッド呼び出しを完全に制御できるため、正しい引数を指定できますが、発生する可能性のあるバグをできるだけ早く検出できるようにするために、内部でそれをアサートすることをお勧めします。可能。
独創的な本、実用的なプログラマーによると、コンパイラーの作成者などがパフォーマンスのオーバーヘッドは許容できないという考えを広め、コードをデバッグするときにのみ問題になるため、アサーションはデフォルトでオフになっています。
実際、テストですべてのバグが検出されない可能性があり、出荷時にカオスモンキーがいつでも攻撃される可能性があるため、アサーションをオンのままにしておくことをお勧めします。アサーションは、パフォーマンスの問題が発生した場合にのみオフにする必要があります。
また、独自のバージョンのassertを作成することをお勧めします。これは、失敗したときに必ずしもexitを呼び出すとは限りません。