web-dev-qa-db-ja.com

Javaのメソッドの各パラメーターの最初の行のnullを常にチェックする必要がありますか？

すべてのメソッドは、パラメーター値のセットを受け入れます。入力パラメータがnullでないことを常に検証する必要がありますか、それとも従来のRunTimeExceptionでコードが失敗することを許可する必要がありますか？

入力パラメータのヌル性を実際にチェックせず、パラメータを使用してビジネスロジックを記述するだけのコードをたくさん見ました。最良の方法は何ですか？

void public( String a, Integer b, Object c)
{
  if( a == null || b == null || c == null)
  {
    throw new RunTimeException("Message...");
  }
  .....business logic.....
}
javamethodsparametersnullvalidation
27
Sanjeev Kumar Dangi

最善の方法は必要な場合にのみチェックするです。

たとえば、メソッドがprivateであり、他の誰もそれを使用していないことがわかっていて、nullを渡していないことがわかっている場合は、再度チェックする必要はありません。

ただし、メソッドがpublicの場合、APIのユーザーが何をしようとするかは誰にもわからないので、よく確認してください。

疑わしい場合はチェックの場合。

ただし、できる最善の方法がNullPointerExceptionをスローすることである場合は、チェックしたくない場合があります。例えば：

_int getStringLength(String str) {
  return str.length();
}
_

nullをチェックしたとしても、合理的なオプションはNullPointerExceptionをスローすることです。これは、とにかくstr.length()が行います。

24
iluxa

いいえ。パラメータがnullにならず、そうでない場合はNullPointerExceptionがスローされると想定するのが標準です。メソッドでパラメーターをnullにできる場合は、APIでそのことを指定する必要があります。

2
Robby Pond

参照がnullになる可能性があることは、Java）の不幸な側面であり、そうでないことを言語で指定する方法はありません。

したがって、一般的にはそうです。nullの解釈を作成したり、後でNPEがスローされる可能性がある状況になったりしないでください。

JSR305（現在は非アクティブ）を使用すると、パラメーターに注釈を付けて、nullsを指定しないように指定できます。

void fn(@Nonnull String a, @Nonnull Integer b, @Nonnull Object c) {

冗長ですが、それはJavaです。ほとんど同じことを行うが、標準ではない他の注釈ライブラリとチェッカーがあります。

（大文字の使用に関する注意：「non-thing」の形式のキャメルケースの単語の場合、 標準 は、クラスの名前でない限り、ルートの単語を大文字にしないでください。したがって、nonthingおよびnonnull。）

チェッカーが実行される場合を除いて、注釈も実際にはルールを適用しません。チェックを行うメソッドを静的に含めることができます。

public static <T> T nonnull(T value) {
    if (value == null) {
        throwNPE();
    }
    return value;
}
private static void throwNPE() {
    throw new NullPointerException();
}

値を返すことは、コンストラクターで便利です。

import static pkg.Check.nonnull;

class MyClass {
    @Nonnull private final String thing;
    public MyClass(@Nonnull String thing) {
        this.thing = nonnull(thing);
    }
    ...
2
Tom Hawtin - tackline

引数のいずれかがnullであると予想するかどうか、より正確には、一部のパラメーターがnullである場合でも、メソッドが正しい決定を行うことができるかどうかによって異なります。

そうでない場合は、nullをチェックして例外を発生させることをお勧めします。そうしないと、NullPointerExceptionが取得されますが、その外観は常にチェックを忘れたことを示しているため、決してキャッチしないでください。コード内の変数。 （そしてそれを捕まえると、それが投げられる他の出来事を見逃すかもしれず、バグを導入するかもしれません）。

一方、RunTimeExceptionまたはその他のカスタム例外をスローした場合は、アップストリームのどこかでそれを処理できるため、何が行われるかをより細かく制御できます。

1
Dan

重要なランタイムパラメータが欠落しているなど、システムの操作にとって本当に致命的な状態でない限り、ランタイム例外をスローしないでください。ただし、システムが起動してはならないため、これには疑問があります。

ビジネスルールは何ですか？フィールドにnullは許可されていますか？そうじゃない？

いずれの場合も、渡されたパラメータを操作する前に、渡されたパラメータのnullをチェックすることをお勧めします。これにより、誰かが不正なデータを渡したときにNullPointerExceptionsを取得しません。

1
Alexx

はい、特に不正な入力がメソッドのコード内で問題を引き起こす可能性がある場合は、パブリックメソッドで入力をスクラブする必要があります。早く失敗するのは良い考えです。つまり、できるだけ早く確認してください。 Java 7は新しいObjectsクラスを追加しました。これにより、nullパラメータを簡単にチェックし、カスタマイズされたメッセージを含めることができます。

public final void doSomething(String s)
{
  Objects.requireNonNull(s, "The input String cannot be null");
  // rest of your code goes here...
}

これにより、NullPointerExceptionがスローされます。

ObjectsクラスのJavadoc： http://docs.Oracle.com/javase/7/docs/api/Java/util/Objects.html

1
james.garriss

いいえ、それを普遍的に行うべきではありません。

私の好みは、順番に、次のようになります。

  1. Nullで賢明なことをしてください。賢明なことは状況に完全に依存しますが、カスタム例外をスローすることを最初に選択するべきではありません。
  2. アサーションを使用してnullをチェックし、徹底的にテストして、-別名バグ以降にnull入力が生成される状況を排除します。
  3. パブリックAPIの場合、nullは許可されていないことを文書化し、NPEで失敗させます。
0
Isaac Truett

これを行うことにはあまり意味がありません。 a、b、またはcを初めて操作しようとしたときに、無料で得られる動作を複製しているだけです。

0
Oliver Charlesworth

それはあなたのコードが何をしようとしているのか、そしてあなたがExceptionを投げたい状況に依存します。メソッドがnull値で正しく機能しない場合は、メソッドが常に例外をスローするようにしたい場合があります。メソッドがnull値を回避できる場合は、おそらく例外をスローする必要はありません。

チェックされた例外を追加しすぎると、非常に複雑で複雑なコードになる可能性があります。これが、C＃に含まれていなかった理由です。

0
Ian Dallas