抛出异常后立即捕获vs重复错误处理：哪种方案更优？

结论是：没有绝对的优劣，得结合实际场景判断，下面从几个核心维度拆解分析：

1. 可读性与维护性：Option 2 占优 #

Option 2 把原本分散在if块和catch块的重复错误处理逻辑统一到了一处，后续如果要修改错误处理逻辑（比如调整日志格式、增加告警动作），只需要改catch块里的代码即可，不用两处同步修改，能降低维护时漏改的风险。

尤其是当错误处理逻辑比较复杂时（比如涉及多个步骤的资源清理、通知推送），这种统一处理的方式优势会更明显。

2. 性能开销：Option 1 占优（高频null场景下） #

你说得没错，异常的抛出和捕获确实有额外开销——JVM需要生成栈轨迹（Stack Trace），这个过程会遍历调用栈收集信息，虽然单次开销不大，但如果result == null是高频出现的正常业务场景，累积起来的性能损耗就不能忽略了。

但如果result == null是罕见的异常情况（比如正常流程下几乎不会触发，只有系统故障、非法输入时才会出现），那这点性能开销完全可以接受，毕竟异常机制本身就是为处理异常场景设计的。

3. 代码语义合理性：看场景 #

异常的核心设计初衷是处理预期外的错误，而不是正常的业务分支：

• 如果result == null是业务上不允许出现的错误状态（比如接口约定必须返回非null值），那Option 2的语义更清晰——通过抛出异常明确告知维护者“这个null是错误，不是正常流程的一部分”。
• 如果result == null是业务上预期的合法情况（比如查询不到数据时返回null），那Option 1的if判断处理更符合语义，用异常来处理正常分支反而会让代码逻辑变得迷惑。

折中方案：抽离公共处理逻辑 #

如果想兼顾可读性、维护性和性能，可以把重复的错误处理逻辑抽成一个独立方法，既避免重复代码，又不用触发异常抛出捕获的开销：

private void processError(Throwable error) {
    // 统一的错误处理逻辑
    logger.error("xxx", error);
}

// 优化后的代码
try {
    String result = x.getResult();
    if (result == null) {
        processError(new RuntimeException("yyy"));
    }
} catch (Throwable t) {
    processError(t);
}

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