1

たとえば、DAO オブジェクトの 1 つの内部でメソッドを記述し、このメソッドが特定の入力を受け入れないようにする場合は、議論のために、null 引数を許可しないとします。この方法が新しいチームメンバーによって将来再利用される可能性があることを考慮して、どのように実装しますか。

私がそれを行う方法は次のとおりです。

  1. インターフェイスでは、引数 a、b、および c を null にすることはできないことをメソッド javadoc 内に文書化しています。
  2. メソッド内で最初に null 値をチェックし、a、b、または c のいずれかが null の場合、IllegalArgumentException をスローします。

しかし、将来、一部の開発者がメソッドのシグネチャを読み取って、必要なものであると判断し、この詳細に注意を払わずに使用を開始し、さらに悪いテストを行ってもそれが明らかにならない場合はどうなるでしょうか。NULL ポインター例外は発生せず、有用なエラー メッセージが表示されますが、本番環境では回避できたはずのエラーが引き続き表示されます。

コンパイル時にこれを強制する方法はありますか? 私はそれを疑っていますが、これを行うための最も安全で、最も悪い開発者に耐えられる方法は何でしょうか?

4

3 に答える 3

4

このコンパイル時間を強制できるとは思いませんが、メソッドのシグネチャを理解しやすくすることは確かにできます。

検証フレームワークのいずれかに依存関係を追加しない場合は、JSR 303の@NotNullまたはPreconditionsなどの同様のツールを使用できます。

JSR 303 を使用すると、次のようなことができます。

@NotNull
@Size(min = 2, max = 14)
@UpperCase
private String licensePlate;

また

@NotNull
@NotEmpty
public String foo(@NotNull @Pattern(regexp="[0-9]") String param) {
   ...
}

より包括的な例については、Getting started with JSR 303 Bean Validationをご覧ください。

于 2012-03-03T10:26:14.857 に答える
1

findbugs などの静的コード チェック ツールで jsr305 を使用して、コミット/リリース前にチェックすることができます。

public String method(@NonNull String parameter ){
   ...
}

注釈に関する findbugs マニュアル

于 2012-03-03T11:10:17.167 に答える
0

  1. コンパイル時に物事を強制するのに最も近いのは、チェックされた例外をスローすることです。これにより、呼び出し元はコンパイル時に例外を処理するように強制されます。これにより、ドキュメントを読むようになる可能性があります。IllegalArgumentException はチェックされておらず、見過ごされる可能性があります。

  2. 使用できない値を保護する通常の方法は、使用できないものを特定した時点で戻り、表示用のエラー メッセージを追加することです。これにより、そのメソッドで実行が継続された場合に発生する可能性のある本番環境での例外が回避されますが、完全に回避されるわけではありません。

于 2012-03-03T11:06:43.553 に答える