不推荐用java异常实现业务流程控制，因其使逻辑隐晦、性能下降、调试困难；异常应仅用于处理非预期错误，而非可预判的业务分支如“库存不足”；替代方案包括optional、状态枚举和结果封装类。
不推荐用 Java 异常实现业务流程控制——它会让逻辑变隐晦、性能变差、调试变困难。
为什么 throw 和 catch 不该当 if 用
异常机制的设计目标是处理「非预期、非常规」的错误情况，比如 IOException、NullPointerException。一旦把它挪去表达「用户名已存在」「库存不足」这类可预判、可检查的业务分支，就违背了 JVM 对异常的优化假设：JVM 会为 try 块做栈帧快照，而 throw 会触发完整栈遍历，开销远高于普通分支判断。
- 每次抛出受检/非受检异常，JVM 都要填充
StackTraceElement[]，哪怕你没打印堆栈 - HotSpot 对频繁抛异常的代码会拒绝 JIT 编译，长期运行反而更慢
- IDE 和静态分析工具（如 SonarQube）会直接报
ThrowingExceptionFromNormalFlow警告
IllegalArgumentException 在构造函数里算例外吗
算，但仅限「参数明显非法且无法恢复」的场景，比如传入负数给表示数量的构造参数。这不是流程控制，而是防御性编程的边界校验。
- ✅ 合理：
new Order(-5)→throw new IllegalArgumentException("quantity must be positive") - ❌ 错误：
new Order(100)因库存不足而抛IllegalArgumentException—— 库存是运行时状态，不是参数固有约束 - 注意：
IllegalArgumentException是 unchecked，调用方无需声明处理，容易掩盖问题
替代方案：显式返回 vs 状态枚举 vs Optional
把「可能失败」变成「必然返回」，让调用方自己决定怎么分支，比硬塞进异常更可控。
立即学习“Java免费学习笔记（深入）”；
- 简单二值结果：用
Optional<order></order>表示「能创建就返回，不能就empty()」，比抛OrderCreationException直观 - 多状态结果：定义
enum CreationResult { SUCCESS, OUT_OF_STOCK, USER_BLOCKED }，方法返回CreationResult，调用方switch处理 - 需要附带数据时：封装类如
Result<order string></order>（类似 Rust 的Result），避免用异常传消息
真遇到必须用异常的边界场景怎么办
只在「错误发生后无法继续当前操作，且上层没有合理方式预检」时才考虑。典型如分布式事务中的最终一致性补偿失败。
- 确保异常类型语义清晰：
InsufficientStockException比RuntimeException好十倍 - 永远在
catch块里做明确动作：记录日志、触发告警、降级返回，而不是空catch或吞掉再抛新异常 - 避免在循环体里抛异常控制流程——一次
for循环抛 100 次NoSuchElementException，性能崩得比内存泄漏还快
真正难的不是写 throw，而是判断「这个条件，到底算错误，还是算常态」。很多人卡在这一步，就默认扔异常最省事——结果半年后自己看代码也得翻三遍堆栈才能搞懂那行 catch 到底想拦什么。
