3

私のAndroidアプリでいくつかの緩いものをクリーンアップすると、開発者コンソールでnullポインタ例外が見つかりました.

ご存じない方のために: Android では、ユーザーがクラッシュ (キャッチされない例外) を開発者に報告することができます。

if (… != null)思いついたとき、私はすでに悪名高いものを入力し始めました。レポートは3つしかありません。そのため、めったに起こりません。

だから私は疑問に思います:この状況では、パフォーマンスに関して:代わりにヌルポインター例外をキャッチする方が良いのではないでしょうか?

if が毎回評価されることを考慮してください。

4

5 に答える 5

8

狂信的な人や偏狭な人のように聞こえるわけではありませんが、そもそもNPEが発生することは決して許されるべきではないと強く信じています! 私の意見では、NPEを捕まえることは非常に悪い習慣です。これは、コードがどのように機能するかを完全に認識していないことを意味します。

入力を使用する前に必ず最初に行うべきことは、null のチェックです。

于 2012-05-01T12:29:08.010 に答える
3

「毎回」とはどのくらいの頻度ですか？ロードごとに1回？毎分？1秒間に1000回？

いずれにせよ、 のテストobj == nullは可能な限り安価な操作であり、例外処理よりも確実に安価です。

また、null ポインター例外は決して発生してはなりません。それらを理解し、防止する必要があります。原因がわからない場合は、修正する必要があります。

于 2012-05-01T12:29:33.983 に答える
2

例外的なケースを処理するには、例外を使用する必要があります。つまり、値が null であることが予想される場合は、例外をキャッチするのではなく、null をチェックするのが合理的です。NullPointerException通常の制御フローで処理するよりもa をキャッチした方がよい例は思いつきません。

于 2012-05-01T12:30:13.250 に答える
0

開発者コンソールで null ポインター例外を見つけましたが、これは決して起こらなかったもので、まれな競合状態であると思います

それはバグのように聞こえますが、例外をキャッチするだけでは、バグを修正するのではなく、バグを無視するつもりのように聞こえます。これらの null 値がどこから来ているかを調べて修正し、null ポインターを処理できないコードに伝達させないようにします。

于 2012-05-01T13:07:02.173 に答える
0

マルチスレッドの競合状態の場合、変数が初期化されてから再び null に設定される可能性がありますか? その場合、「if (... != null)」はパスする可能性があり、それでも例外が表示されます。

安全のために try catch を使用します (未処理の null ポインター例外は回避する必要があります) だけでなく、競合状態を見つけようとし、可能または監視可能な時間内に管理できる場合は、それを修正または処理します。

例外が競合状態をバイパスするように見える場合は、数ミリ秒待ってから一定時間再試行することもできます (あまりきれいではありませんが機能します)。

于 2012-05-01T12:32:57.023 に答える