3

try私は最近、sのcatchブロックを使用することNullPointerExceptionは悪い習慣であることを知りました。

もしそうなら、私は次の質問があります：

  1. なぜこれは悪い習慣ですか？
  2. キャッチするための代替手段は何NullPointerExceptionですか？
4

5 に答える 5

8

特定の状況下で NPE をスローすることが予想されるコードのセクションの周りに try/catch ブロックを追加すると、そのコードで使用されている別のオブジェクトが null である可能性があることをうっかり忘れてしまう可能性があります。その後、予想される NPE に反応するコードを catch ブロックに追加すると、そのコードは予想外の NPE でも実行されます。これにより、せいぜい誤解を招くようなエラー メッセージが出力され、最悪の場合、完全に予期しないプログラムの動作が発生します。

例：

try {
    ThingamabobFactory.getInstance().createThingamabob(ThingamabobFactory.getDefaults()).thingamabobify();
} catch(NullPointerException e) {
      // so... which of the above method calls did return null?
      // ...or was the NPE even thrown INSIDE one of these methods??
}

そのため、ある状況でオブジェクトが null になることが予想され、このケースを処理したい場合は、if (object == null)誤検知を回避するためにチェックしてください。

于 2013-01-22T21:59:42.553 に答える
4

NullPointerException をキャッチする際の大きな問題は、それに対して何をすべきかを知ることです。これには非常に多くの原因が考えられるためです。

特に null をテストすると、何が null で、その理由をより確実に知ることができます。たとえば、特定の状況下で null を返すメソッドの呼び出しがコード ブロックに含まれており、その場合に何らかのアクションを実行したいとします。メソッドの結果をすぐにテストすると、null は、メソッドが null を返す状況によるものであることがわかります。

一方、ブロックを try-catch でラップして NullPointerException をキャッチすると、メソッドが null を返した可能性がありますが、それが実際に起こったことかどうかはわかりません。try ブロックで別の何かが間違っていて、例外が発生している可能性があります。

于 2013-01-22T22:01:42.640 に答える
0

例外を生成してアプリを介して送信するとリソースが高価になるため、可能であれば例外を避ける必要があります。

null ポイントは簡単に処理できます。何かが null かどうかを確認するだけです。

于 2013-01-22T21:56:01.077 に答える
0

スローを使用して直接処理することを回避するか、 BCELを使用して別の方法を試すことができます。

于 2013-01-22T22:01:45.160 に答える