10

引数がデータベースに存在する場合にID番号を返す関数があります。そうでない場合は、nullを返します。これはnullポインタ例外を懇願していますか?負のID番号は許可されていませんが、存在しない引数が-1のようなエラーコードの代わりにnullを返す方が明確だと思いました。どう思いますか?

private Integer tidOfTerm(String name) throws SQLException {
    String sql = "SELECT tid FROM term_data WHERE name = ?";
    PreparedStatement prep = conn.prepareStatement(sql);
    prep.setString(1, name);
    ResultSet result = prep.getResultSet();

    if (result.next()) {
        return result.getInt("tid");
    }

    return null; // TODO: is this begging for a null pointer exception?
}
4

14 に答える 14

16

これは完全に合法です。NPEを回避したい場合は、カスタム例外をスローします。ただし、負の数を返さないでください。呼び出し元が戻り値をチェックしない場合、常に問題が発生します。ただし、誤った計算を行うと(たとえば、結果に-1が掛けられるため)、キャッチされていない例外よりもデバッグが確実に困難になります。

于 2010-01-24T19:44:26.440 に答える
3

結果が得られないルックアップの場合にaを返すことnullは、存在しないことを表す通常の方法です。この場合はそれを選びます。(標準のJava Mapクラスのルックアップメソッドはnull、マップにキーが含まれていない場合に使用する例です。)

IDの特別な値を返すことに関しては、システムに特別なIDを表す特別な値がすでに含まれている場合にのみそれを行うことを提案します。

この場合、よく聞かれるもう1つの可能性は、例外をスローすることです。ただし、状態を渡すために例外を使用するのは賢明ではないので、私もそうしません。

于 2010-01-24T19:47:43.910 に答える
2

この場合、nullを返すのは正当だと思います。意図が適切に文書化されていることを確認してください。

この場合、負の値を返すことは問題ありませんが、万能の解決策ではありません。データベースで負の値が許可された場合はどうなりますか?

編集:nullまたは空のリスト(または配列)を返すことに関するSOに関する関連する議論について一言追加したいと思います。nullではなく空のリストまたは配列を返すことに賛成ですが、コンテキストが異なります。リストを取得しようとすると、通常は親オブジェクトの一部であり、実際には、親オブジェクトがnull参照ではなく空のリストを持つことは理にかなっています。この場合、nullには意味があり(=見つかりません)、それを返すことを避ける理由はありません。

于 2010-01-24T19:31:49.577 に答える
1

これがあなたにとって本当の方法ではないことを願っています。メソッドスコープでStatementまたはResultSetを閉じていません。

于 2010-01-24T19:32:44.403 に答える
1
  • エラーコードを使用しないでください!エラーはどの値ですか?法的な戻り値になることはありませんか?何も勝ちませんでした。

  • ヌルは良くありません。ほとんどの呼び出し元コードは、結果に対してnullでない場合はチェックを実行する必要があります。また、selectがnullを返す場合もあります。行がない場合とは異なる方法で処理する必要がありますか?

  • nullを返す代わりに、NoSuchElementExceptionのような例外をスローします。これはチェックされていない例外であり、呼び出し元はそれを処理するか、渡すことができます。また、呼び出し元が処理したい場合、trycatchはnullでない場合よりも複雑ではありません。

于 2010-01-24T20:25:47.357 に答える
1

オプションパターンを検討することをお勧めします。

オプションパターンは、返された型のラッパーとして機能し、option.none()とoption.some()の2つの特殊なケースを定義します。そうすれば、返されたタイプ(オプション)を常に把握し、option.isSome()やoption.isNone()などのメソッドを使用して、返されたOptionオブジェクトに値があるかどうかを確認できます。

このようにして、チェックされていないnullがないことを保証できます。

もちろん、これにはすべて、コードがさらに複雑になるという犠牲が伴います。

オプションタイプの詳細については、ここを参照してください(Scalaコードですが、プリンシパルは同じです)

于 2010-01-24T21:52:31.080 に答える
0

いいえ、ありません。後でヌルチェックせずにプリミティブであるかのように操作を行った場合にのみ、NPEがスローされます。たとえばi++、など。あなたの例は有効です(JDBCコード自体がリソースをリークしていることを期待してください)。実際のを必要としない場合はid、一方で、を返すこともできますboolean

于 2010-01-24T19:29:07.010 に答える
0

初心者の方には大きなトラブルになるかもしれません。優れたコーダーは、名前が無効な場合はnull返される可能性があることを認識します。より標準的なことはいくつかを投げることだと言ったexception

于 2010-01-24T19:46:49.027 に答える
0

オートボクシングの組み合わせでは注意が必要な場合があります。私がこれをしている場合:

final int tid = tidForTerm("term");

そして、「term」は存在しません。Javaが整数(null)をプリミティブintにアンボックスしようとするため、NPEを取得します。

それでも、整数にnullを使用するのが実際に良い場合があります。オプションのint値を持つエンティティ、たとえば都市の人口。その場合、nullは、利用可能な情報がないことを意味します。

于 2010-01-24T20:17:09.193 に答える
0

興味深い問題と考えられる解決策の数:

  1. HasArgumentメソッドを作成し、ユーザーにそれを呼び出すように要求します。これは遅く、重複した作業になる可能性があります。
  2. 値がデータベースにない場合は例外をスローします。これが予期しない場合にのみ使用する必要があります
  3. 追加の値を使用して無効な戻り値を示します。null値と負の値は機能しますが、チェックしないと、コードの後半で問題が発生する可能性があります。
  4. isValid()メソッドとgetValue()メソッドを使用してラッパーを返します。ここで、getValue()は、無効な場合に例外をスローします。これは1と3の問題を解決しますが、少し多すぎるかもしれません。
于 2010-01-24T21:34:20.710 に答える
0

最善の解決策は、メソッドの名前に依存すると思います。メソッドの名前は、nullを返すか、例外をスローするかだけでなく、検討する必要があります。

tidOfTerm用語が存在することが期待されていることを私に暗示しているので、用語が存在しないことを発見すると例外がスローされます。

用語名が独自のコードの管理下にあり、それが見つからない場合は、コードまたは環境にバグがあることを示している場合は、IllegalArgumentExceptionをスローすることをお勧めします。

用語名の引数が制御できず、有効な用語が見つからないことが完全に有効な状況である場合は、メソッドの名前findTidForTermNameを、ある種の検索が実行されることを少し示唆するような名前に変更します。したがって、検索で何も見つからない可能性があります。

于 2010-01-24T22:40:55.193 に答える
-3

私はポスターに同意します。整数はラッパーであるため、計算や変換などに使用する必要があります(これはあなたが意図していることだと思います)。nullを返さないで、負の数を使用してください...もう少しエレガントで、より詳細に制御できます。私見では。

于 2010-01-24T19:33:31.673 に答える
-3

はい、それはNPEを引き起こしているはずであり、はい、呼び出し元のメソッド(または他の適切な場所)でそれをキャッチしているはずです。メソッドがNULLを返す最も可能性の高い理由は、レコードがなく、それを処理する適切な方法が例外をスローすることである場合です。そして、あなたが彼が求めたものを持っていないことを誰かに伝えるための完璧な例外はNPEです。

エラーコード(例:-1)を返すことは、次の理由で適切ではありません。

a)処理したいエラーが多数ある場合(たとえば、DBを読み取れない、DBを読み取れるが、オブジェクトがDBに存在しない、オブジェクトが見つかったが何かが破損しているなど)、エラーコードを返すと、次のタイプが区別されません。エラー。

b)将来、-1が有効な用語IDになった場合、それを変更することは困難になります(-1を使用する必要がある場合は、(Cで編集:)少なくとも#define ERRORCODE -1を実行し、どこでもERRORCODEを使用します)

于 2010-01-24T19:42:09.273 に答える
-3

nullを返すコードを記述しないでください。これは、コードを呼び出すたびに、堅牢にするためにnullをチェックする必要があることを意味します。毎回。いつも。

ゼロになる可能性のある戻り値の数を含む代わりに、リストを返すことを検討してください。

于 2010-01-24T20:17:45.260 に答える