为什么不建议使用异常控制业务流程 (1)

面试回答¶

面试官：为什么不建议用异常来控制业务流程？

你：

一句话：异常是用来处理“意外”的，不是用来处理“预期分支”的。用异常控制流程，既慢、又乱、还不安全。

第一个问题：性能开销巨大。 Java 的异常机制在抛出时会调用 fillInStackTrace()，需要遍历整个栈帧生成异常快照，涉及大量 JNI 本地调用。抛出一次异常可能比普通条件判断慢几千倍。如果把它用在正常的业务逻辑中（比如库存扣完就抛异常通知外层），在高并发下 CPU 会大量消耗在构建异常堆栈上，直接影响吞吐。

第二个问题：代码可读性和可维护性极差。异常机制本质上是一种“goto”，它会打断正常的线性执行流，把错误处理与业务逻辑割裂开来。如果用异常来切分业务流程，读者根本看不出一条请求的主路径是什么，满屏的 try-catch 和隐式跳转会变成“意大利面代码”。这违反了最少惊讶原则。

第三个问题：容易掩盖真正的错误。你把正常分支处理成异常，一旦系统真的发生你未预料的、致命的异常，可能会被外层宽泛的 catch (Exception e) 当作“正常业务错误”吞掉，真正的系统故障反而被雪藏了，线上排错无从下手。

正确做法：用返回值或条件判断表达业务状态。比如 Optional、返回结果码、null 判断，或者使用“先检查后执行”的模式。对于复杂状态，可以用状态模式或者有限的 switch 分支，保持主流程清晰。

Mermaid 时序图：异常控制流 vs 条件判断

总结：异常只留给意外，业务分支交给代码逻辑。当你想用异常来控制流程时，停下来想一想：“这种情况是意外，还是预期的一种结果？”如果是后者，老老实实写条件判断。