在代码评论中，我偶然发现了这个java模式以避免NPE：
value = (null != someObject) ? someObject.someOtherMethod() : null
我怀疑这是“好风格”。我宁愿认为它委托NPE（BTW这听起来类似于Scala-Option-value或Haskell-Maybe ...的映射）
风格好不好？如果没有，如何改进？
编辑：假设它散布您的代码，代码将变得不可读： 这是否已经封装在一些库/ API中？（apache-commons，google-coomons或类似的东西！？）
答案 0 :(得分：3)
这种模式既不好也不好。您需要在上下文中对其进行评估。
关键问题是为什么someObject可以有null个值，以及它是否有意义......或者是错误。
一方面，null可能具有特定含义（例如“值未指定”），代码可能以合法的方式处理该问题。
另一方面，null可能是错误的症状（例如，某人忘记初始化某些内容）。在这种情况下，代码正在传播损害和/或使错误的来源更难找到......因此很糟糕。
作为一般观察，许多代码/编码员认为避免意外NPE的最佳方法是在整个代码库中自由地分散这样的东西作为预防措施。事实上，这是完全错误的事情。正确的方法是让NPE发生（或者更好的是，强制它发生 - 请参阅@ vacuum的答案），弄清楚意外的null来自哪里......并删除源。并且（当然！）您需要进行广泛测试，以便在投入生产之前获取意外的空值。
IMO，最佳做法是将null视为错误，除非具有明确定义和记录的含义。
答案 1 :(得分：2)
也许Guava会帮助你。
答案 2 :(得分：1)
如果null最终能够得到优雅处理但无法在那里处理，那么这是一个非常合理的模式。
如果null肯定无法妥善处理，那么它会适得其反。最好快速失败。
答案 3 :(得分：0)
这个成语不可能封装在API中。它需要一流的语言支持（或者语言需要支持宏），特别是如果你想在return-derefence-return链中推广到任意多个步骤。
我喜欢避免使用这些类型的检查乱丢代码，因此在某些项目中，我发现自己使用了一段接受字符串的反射代码，它将其解释为方法调用链，并做正确的事情。当然，类型不安全，但很多时候并不是主要问题。