用try/catch包裹取值操作替代空值检查是否合理？

Great question—let’s unpack this scenario clearly, since it’s a common pattern that splits opinions.

首先，你的核心观察完全正确 #

你提到抛出异常的性能开销远高于多次空值检查，这一点没毛病。Java里异常的创建会生成完整的栈轨迹，这个过程的开销比几个简单的null判断要大得多，尤其是当空值场景出现得比较频繁时，这种写法会带来不必要的性能损耗。

为什么有人会这么写？ #

通常有几个动机，但大部分时候都站不住脚：

• 追求代码简洁（但过度了）：如果链式调用很深（比如a.getB().getC().getD().getValue()），写一堆if (a != null && a.getB() != null && ...)确实显得冗长。但你也提到，你看到的这类代码大多能轻松改成简单的if语句——那这种情况下，用try-catch就纯粹是为了少写几行代码，属于偷懒。
• 对异常的误用：有些开发者错误地把“预期的空值”当成了“异常情况”。异常设计的初衷是处理意外的、不应该发生的错误，如果空值是业务逻辑里可能出现的正常情况，用异常来处理就完全违背了这个原则。
• 不知道更优雅的替代方案：比如Java 8+的Optional可以用更简洁的方式处理链式空检查，比如：

  String value = Optional.ofNullable(pojoClass)
      .map(Pojo::getValue)
      .map(NestedObj::getANumberOfFunctions)
      .orElse(null);
  

  这种写法既简洁，又没有异常的性能开销，还能清晰表达逻辑。

这算不算“偷懒式编程”？ #

大部分情况下，是的。尤其是当空值是预期场景、且空检查代码并不复杂时，这种写法就是为了省事儿，却牺牲了性能和可调试性——你提到的“不利于调试”是关键痛点：catch块直接忽略异常，出问题时根本不知道是链式调用的哪一层出现了空值，定位问题要花更多时间。

有没有你没理解的深层原因？ #

极少数情况下，这种写法可能有合理的理由，但非常罕见：

• 如果链式调用中的某个方法本身就会在非空值时抛出其他异常，而开发者想统一捕获所有可能的异常（但你的场景里明确说只有空值会抛异常，所以不适用）。
• 某些老旧代码库中，团队有不合理的约定，但这属于历史遗留问题，不是合理的设计选择。

总结 #

你并没有忽略什么——这种写法在你的场景下（空值是预期情况、空检查容易实现）就是不恰当的。建议替换成显式的空检查，或者用Optional这类工具类来兼顾简洁性和性能。

内容的提问来源于stack exchange，提问作者Neuromante