web-dev-qa-db-ja.com

「nullポインター例外を回避するために、myString.equals( "abc")の代わりに "abc" .equals(myString)を使用する」は、ビジネスロジックの観点からすでに問題がありますか?

Javaで文字列を比較するとき、nullポインタ例外を回避するために、myString.equals( "abc")の代わりに "abc" .equals(myString)を使用する必要があると何度も聞いたが、私の質問は、このアイデアはすでに問題があるビジネスロジックの用語?

「abc」.equals(myString)を使用してnullポインター例外を回避する場合、通常の状態ではmyStringを空にしないでください。null文字列の根本原因に関連するいくつかのバグを見逃す可能性があります(例:不完全なフォーム)フィールドまたはデータベースに対応する列がありません)。そのため、nullポインター例外を自然にスローさせるか、常に最初にnullを常にチェックする必要があります。

if(myString==null){
}else if(myString.equals("abc")){
}

バグを見つけることができるか、少なくともnull入力を引き起こす異常な状態を処理するルートがあることを確認するために、それは本当ですか?そして、nullでも有効であると想定されます。

if(myString==null || myString.equals("")){
}

他の開発者を強調または思い出させるために、私はnullが通常であると思いますか?

5
ggrr

"abc".equals(...)を使用することは、予想外の状態に対する妥当な予防策ですが、実際には問題を解決しません。たぶん、この特定のメソッドはmyStringがnullであることを気にしません(文字列比較はfalseを返しますが、それだけです)が、他の場所はどうですか?これで、本来あるべきではないロジックを通じて、このnull値が機能するようになりました。

この特定のケースでは問題にならない可能性がありますが、別のケースでは、この無効な値をロジックの一部に通すと、後で間違った状態になる可能性があります(たとえば、都市が欠落している住所)。 早く失敗します!

myStringをnullにしない場合は、nullにならないようにコードを記述します。メソッドにコントラクトを追加するか、メソッドのロジックが実行される前に無効な値が処理されるように、少なくともメソッド内の引数の検証を行います。次に、テストがこれらのケースをカバーしていることを確認してください。

15
Dan1701

MyStringがnilの場合、一方のバージョンは例外をスローし、もう一方は、最初に読む必要があるドキュメントに従って何かを行います。等しいかどうか文字列をnilと比較すると "false"が返されると仮定します。

可能性:myStringがnilになることはなく、問題ではありません。または、ソフトウェアにバグがある場合にのみmyStringはnilであり、開発者の注意を引く何かにつながると思われる予期しない例外が良いことです。 (これは、例外をキャッチして何もしないことは致命的です)。または、myStringを合法的にnilにして、比較でfalseを返し、それに応じて比較することもできます。または、myStringがnilであることは特別な処理を必要とする例外的なケースであり、まだ気付いていない可能性があります。その後、予期しない例外により、ある時点で正しい処理が追加されます。

面白いことに、Objective-Cではまったく逆です。nilと比較すると例外がスローされ、nilを何かと比較するとNO(falseとほぼ同じ)が返されます。したがって、あなたが何をするにせよ、Objective-Cの開発者は正反対のことをすべきです!

1
gnasher729

プログラミングの1つの目標は、堅牢なコードです。 しないのコードは、予期しない何かが発生するたびに恐ろしく死ぬ。

if ("abc".equals(myString))の場合、文字列がnullの場合、if句は実行されないため、例外をスローする必要はありません。もちろん、コード内のバグが原因である可能性もありますが、開発/テスト中にnotが顧客によって発見されるはずです!

実際、私は"abc".equals(myString)を、プログラマーが文字列がnullかどうかを明示的に気にしていないことを示すものと見なします。重要なコードでは、もっと明示的なチェックを期待しています。

1
ths

「abc」.equals(...)を使用することは、予期しない状態に対する妥当な予防策です

私は実際に、約2年前に私の会社のコードの簡潔さを維持しながらNullPointerExceptionを回避するソリューションとしてこれを思いつきました。それは確かに私にとって合理的なアプローチです。これを書くスタイルは少し奇妙に見えるかもしれません。私のチームは実際にこの種の文章を笑いましたが、彼らはそれが正当であることを認識し、これが現在私たちの組織の標準として確立されています。

0
Jay