0

在代码审查中，我偶然发现了这个 java 模式以避免 NPE：

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 的最佳方法是在整个代码库中自由散布此类内容作为预防措施。事实上，这完全是错误的做法。正确的方法是让 NPE 发生（或者更好的是，强制它发生——参见@vacuum 的答案），找出意外null的来源......并移除源头。而且（当然！）您需要进行广泛的测试，以便在投入生产之前发现意外的空值。

IMO，最好将 anull视为错误，除非它具有明确定义和记录的含义。

于 2012-10-30T09:43:53.853 回答
2

也许番石榴会帮助你。

另见类似问题。

于 2012-10-30T09:41:33.057 回答
1

如果null最终可以优雅地处理但不能在那里处理，那么这是一个完全合理的模式。

如果null确实不能优雅地处理，那么它会适得其反。最好快速失败。

于 2012-10-30T09:45:29.040 回答
0

这个习惯用法是不可能封装在 API 中的。它需要一流的语言支持（或者语言需要支持宏），特别是如果您想概括为返回-取消引用-返回链中的任意多个步骤。

我喜欢避免用这些检查乱扔代码，所以在一些项目中，我发现自己使用了一段反射代码，它接受一个字符串，它解释为一个方法调用链，并且做正确的事情。当然，类型不安全，但很多时候这不是主要问题。

于 2012-10-30T09:45:17.513 回答