0

コードレビューで、NPEを回避するためにこのJavaパターンに出くわしました。

value = (null != someObject) ? someObject.someOtherMethod() : null

これが「いいスタイル」だとは思えません。私はむしろそれがNPEを委任していると思います（ところで、これはScala-Option-valueまたはHaskell-Maybeを介したマッピングに似ているように聞こえます...）

いいスタイルですか？そうでない場合、どのように改善しますか？

編集：それがあなたのコードを分散させると仮定すると、コードは読めなくなります： これはすでにいくつかのライブラリ/ APIにカプセル化されていますか？（apache-commons、google-coomonsまたは同様のもの！？）

4

4 に答える 4

3

このパターンは良くも悪くもありません。コンテキストで評価する必要があります。

重要な問題は、なぜ値someObjectを持つことができるnullのか、それが意味のあるものなのか、それともバグなのかということです。

  • 一方でnullは、特定の意味 (たとえば、「値が指定されていない」など) があり、コードはそれを正当な方法で処理している可能性があります。

  • 一方、nullバグの兆候である可能性があります (たとえば、誰かが何かを初期化するのを忘れた)。その場合、コードが被害を広げたり、バグの原因を見つけにくくしたりしているため、悪いことになります。

一般的な観察として、多くのコード/コーダーは、予期しない NPE を回避する最善の方法は、予防策としてコードベース全体にこのようなものを自由に分散させることであると考えています。実際、これはまさに間違ったことです。null正しいアプローチは、NPE を発生させ (または、強制的に発生させます。@vacuum の回答を参照)、予期しないものがどこから来ているのかを把握し、ソースを削除することです。そして (もちろん!) 本番環境に入る前に予期しない null が検出されるように、広範囲にテストする必要があります。

IMO、明確に定義され文書化された意味がない限りnull、 aをエラーとして扱うのがベストプラクティスです。

于 2012-10-30T09:43:53.853 に答える
2

多分グアバがあなたを助けるでしょう。

同様の質問も参照してください。

于 2012-10-30T09:41:33.057 に答える
1

最終的には適切に処理できるが、そこでは処理できない場合null、それは完全に合理的なパターンです。

確実に優雅に処理できない場合null、それは逆効果です。早く失敗する方がいいです。

于 2012-10-30T09:45:29.040 に答える
0

このイディオムをAPIにカプセル化することは不可能です。特にreturn-derefence-returnチェーンの任意の数のステップに一般化する場合は、ファーストクラスの言語サポートが必要になります（または言語がマクロをサポートする必要があります）。

私はこの種のチェックでコードを散らかすことを避けたいので、いくつかのプロジェクトでは、文字列を受け入れ、メソッド呼び出しのチェーンとして解釈し、正しいことを行うリフレクションコードを使用していることに気付きました。もちろん、タイプは安全ではありませんが、多くの場合、それは大きな問題ではありません。

于 2012-10-30T09:45:17.513 に答える