4

私は最近、同僚に次のような声明を出しました。

NullReferenceExceptions を 明示的にキャッチしてはなりません

私は決して言葉を使いませんでした....うーん。それらをキャッチするための適切なユースケースを見たことはありませんが、他の誰かが持っているかどうかを確認したかったのですか?

決してそんな強い言葉じゃないのに……。

4

6 に答える 6

6

理由によります。Eric Lippert のブログ エントリを参照してください。それらが「骨の折れる例外」である場合は、いいえ-呼び出しコードを修正するだけです。それらが「厄介な例外」であるというまれなケース（つまり、呼び出しているコードに回避するのが難しいトラップがある場合）では、そうする必要があると思います。

于 2009-02-25T10:35:41.733 に答える
4

時折 nullref を引き起こすバグのあるサード パーティ製ライブラリを呼び出す場合、それらを適切に処理する方法を知っている場合は、それらをキャッチすることをお勧めします。

実生活の例 : 過去に、サード パーティのエディターが提供するデータグリッドをかなり広範囲に使用してきました。基になるデータ ソースの一部のデータを更新するときに、ときどき nullref (コール スタックの奥深くにネストされている) をスローするバグが確認されています (または現時点で確認されています)。

私はこのコードで状況に対処しました:

            try
            {
                // do the update
            }
            catch (NullReferenceException)
            {
                try
                {
                    // redo the update
                }
                catch (NullReferenceException ex)
                {
                    // properly log the third party lib failure
                }
            }

ところで、私の「ログ」コードは 2 年間一度も実行されていません :) 現在、サードパーティのエディタが問題を修正しており、おそらくこのコードを削除する必要があります。

于 2009-02-25T10:32:33.223 に答える
1

そうです、「決して」は強い言葉です。

NullReferenceException (または Java の NPE) のキャッチは、常にコードの目的に依存します。

たとえば、アプリケーションが潜在的に不確実な状態であっても処理を続行する必要がある場合 (生命維持システムを考えてください)、またはコードが参照されたオブジェクトの状態を気にしない場合 (例: 文字通り、悪いデータをスローするバッチ処理データ) ）。

これらのタイプの例外をキャッチしないのは経験則ですが、法則ではありません。

于 2009-02-25T14:17:51.903 に答える
0

私は決して言いません。たとえば、それをキャッチして例外をログに記録したり、あるスレッドから別のスレッドにマーシャリングしたりできます。どちらの場合も、例外を再度スローする必要があります。

Marc Gravell が指摘しているように、Eric Lippert は彼のブログに例外に関する非常に優れたエントリを掲載しています。

于 2009-02-25T10:42:08.567 に答える