The King's Museum

ソフトウェアエンジニアのブログ。

【Effective Java】項目38:パラメータの正当性を検査する

第6章が終わったので『第7章:メソッド』に入る。

この章は一般的な話なのですぐに終わりそうだ。

パラメータをチェックする

ほとんどのメソッドとコンストラクタは、渡されるパラメータに関して何らかの制限を持っています。 この制約は文書化し、メソッドの先頭で制約が満たされているかをチェックするべきです。

制約をチェックしないまま、あとの計算時にエラーが発生すると原因が非常に分かりづらくなります。 明示的にエラーとなればまだましです。 不正な状態のままプログラムが動き続け、まったく関係ないところでエラーとなると不運なことになります。

パラメータの制約が守られない場合にスローされる例外は Javadoc の @throws タグに記述するべきです。 その例外は一般的には、以下のうちのどれかになるでしょう。

コンストラクタでのチェック

パラメータのチェックはコンストラクタでも行うべきです。 これは「実際の計算を行う前にパラメータをチェックするべき」という原則に基づいています。

コンストラクタで無効な値が設定され、のちのちのメソッド呼び出しでエラーが発生するよりも、エラーが発生すると分かった時点で例外が発生したほうがうれしいでしょう。

ただし、コストが高すぎて事前にチェックすることが正当化されない場合もあります。 例えば Collections.sort() のケースでは、事前にすべての要素が相互比較可能であることをチェックするのは現実的ではありません。

このような場合であっても、計算の中でチェックが暗黙的に行われることは確認してください。 どのような場合でも、チェックは必ず行われるべきです。

アサーション

公開されないメソッドはメソッドのユーザーが限定されるため、正当なパラメータだけが渡されることを仮定できます。 そのため、明示的な検査で例外を発生させるのではなく assertion をつかうべきです。

assertion の条件が成り立たない場合、AssertionError がスローされます。 ただし、Java 実行環境に -ea フラグを渡して有効にしない限り、アサーションは有効になりません。 そのため、ほとんどのプロダクション環境では assertion によるパフォーマンス劣化は起こりません。

(c) The King's Museum