21

効果的な Java は、すべきではないことを推奨していcatch NullPointerExceptionます。それは常に正しいですか?

キャッチの多くの場合、NullPointerExceptionボディのみをキャッチしますprintStackTrace()

NullPointerExceptionをキャッチしてコールしない場合、発生しprintStackTrace()た場所を確認するにはどうすればよいですか?exception

また、キャッチNullPointerExceptionしてcatchボディが空の場合、その時点でスタック情報を取得できませんか?

アップデート

Google Android ソース AOSP4.2.2_r1.2 で RuntimeException をキャッチする統計を分析しました。

249 の RuntimeException キャッチがあり、以下は catch-body の統計です。

42%: throw it again as other Exceptions (RuntimeException: 33%, others: 8%)

32%: just return null or 0/false/true or other default values

14%: just call log or printstacktrace

5%: just comment like "// Fall through.", "// ignore, not a valid type.", "// system process dead", "// do nothing"

2%: empty body

3%: display error messages or send fail codes (ex. network service discovery failed: replyToMessage(msg, NsdManager.STOP_DISCOVERY_FAILED, NsdManager.FAILURE_INTERNAL_ERROR); )


3%: intialize or reset related variables.

ほとんどの場合、dalvik と外部は、他の例外をスローして NPE を処理します。

ただし、フレームワークは通常、null またはその他の値を返すことで処理します。

  1. catch-body で他の例外をスローすることは、悪いことでも良いことでもないと思いますか?

  2. より高いレベル (アプリケーションなど) で NPE が発生し、アプリが完全に独立しているため、開発者が例外が重大ではないことを確認した場合、開発者が NPE をキャッチして無視することを受け入れることができますか?

後もう一つ、

google androidフレームワークのソースコードは、いくつかの点で不安定である可能性があると結論付けることができますRuntimeExceptionか?

4

10 に答える 10

2

NullPointerException通常、コードの論理エラーが原因で発生します。NullPointerException安全でない操作を回避することで排除できます。それでも発生する場合NullPointerExceptionは、 で確認できますStackTrace

例えば

if (Obj.getName("Sam")) {
    // only executes if Obj != null
}  

次のように回避できNullPointerExceptionます

if (Obj == null){
    System.out.println("Null Obj, Can't proceed");
} else {
    Obj.getName("Sam")
}
于 2013-08-16T04:49:09.007 に答える
2

一般的には、キャッチNullPointerException せずに JVM で処理することをお勧めします。

しかし、それはすべて依存します。たとえば、次のようなコードがある場合List<Student> listStudent = getAllStudent();

ここgetAllStudent() で DB に接続し、結果を表示します。ここでは、リスト オブジェクトに対して操作を行う前に、次のことを確認する必要があります。

if(listStudent != null){ 
    //do the task. 
}else{ 
    //Show Message like no student is there instead of catching NullPointerException 
}

そうしないと、NullPointerExceptionデータがない場合に発生する可能性があります。

したがって、Null をチェックすることをお勧めしますが、次のように処理しないでください。

try{ 

}catch(NullPointerException e){

}
于 2013-08-16T04:51:27.343 に答える
1

慣習として、あらゆる種類の実行時例外をキャッチしないようにします。その理由は、何か恐ろしい問題が発生したためです。開発者は 30 分前に修正することに熱心である必要があります。

NullPointerException実際、 は のサブクラスですRuntimeException。の親を持つ他のクラスと同様にRuntimeException、それらはチェックされていないと見なされます。そのため、コードは NPE を生成する場合でもコンパイルされます。

// This would appropriately return "false", if the order were reversed 
// and something was empty.
public boolean doSomething(String something) {
    String hello = null;
    if(hello.equals(something)) {
        System.out.println("Wow");
    }
}

何らかの種類の実行時例外を明示的にキャッチするということは、プログラムの過程で恐ろしい、悪いことが起こると予想していることを示しており、その事実を無視したいということです。

ブロックの本体に何が入るかについてはcatch...おそらくIDEによって自動的に生成されます。例外をアプリケーションの上位レベルに伝播しない場合は、プログラムが異常終了した理由に関する有用なコンテキストを取得する必要があります。

catch ブロックに何も入れないと、黙って無視されます - これは悪いことです。

于 2013-08-16T05:10:29.307 に答える
1

本当に重要な理由がない限り、空の catch ブロックを使用しないでください。通常、そのような理由はありません。

通常は、変数が null かどうかを確認するか、NPE をキャッチしてより適切な理由を調べることをお勧めします。たとえば、メソッドgetCar()が返された場合、 のメソッドnullを呼び出そうとしたときに NPE をキャッチしcarたり、車がnullスローされているかどうかを確認したりできますRuntimeException(ただし、状況が本当に例外的な場合のみ)。したがって、エラーをより抽象的にバインドし、理解しやすくします。

于 2013-08-16T04:51:17.037 に答える
0

堅牢でユーザー中心のコードは、何かできることがあれば、そのような「致命的なエラー」をキャッチしようとする必要があります。試行された関数呼び出しを再試行できます。おそらく、この null 例外は一時的なものによるものです。実際には例外をスローすべきではなく、一時的な障害に対してより適切にコーディングする必要がありますが、長いステートフルなフォーム入力プロセスになる可能性があるものを放棄する代わりに、エンド ユーザーが望むものを取得することを妨げてはなりません。ユーザーの電子メール設定を入力するなど、最後のまったく重要でないステップで、ヌル ポインター エラーが発生し、ユーザーの既存の入力が破棄されます。

于 2013-08-21T20:17:04.667 に答える
-1

実際にe.printstacktrace()常に行う必要はありません。ロガーまたはを使用して独自の本文メッセージを指定できます。System.out.println()

于 2013-08-16T04:47:44.413 に答える