不推荐用异常做业务逻辑控制，因其将可预判的业务分支伪装成意外错误，导致性能损耗（开销为if判断的3–10倍）、语义混乱、调试困难、测试复杂，并掩盖真实问题；应改用Optional、枚举、Result封装或预检等显式方案。
不推荐用异常做业务逻辑控制，因为它把“本该预料到的情况”伪装成“意外错误”，既违背设计本意，又带来实际损害。
性能代价远高于普通判断
每次 throw 异常，JVM 都要生成完整堆栈信息、展开调用帧、触发栈遍历——这些操作开销是 if 判断的 3–10 倍。高频场景下（比如循环内校验、API 批量处理），性能会明显下滑。JIT 编译器还会对频繁抛异常的代码降级优化，长期运行反而更慢。
- 避免在 for 循环里靠 catch NoSuchElementException 来终止遍历
- 不要用 file.delete() 后捕获 IOException 判断文件是否存在——应先调用 file.exists()
- 解析 JSON 失败是常见情况，不该每错一次就抛 JsonProcessingException 再 catch
语义混乱，掩盖真实意图
异常本意是表达“程序无法继续执行的意外状态”，比如数据库连接中断、磁盘写满、网络超时。而“用户名已存在”“库存不足”“订单状态不允许取消”都是业务规则下的正常分支，属于可预判、可检查、可恢复的情形。
- 用 PermissionDeniedException 控制权限跳转，不如直接 if (!user.hasPermission("edit")) return forbidden();
- 构造函数中 throw IllegalArgumentException 检查负数数量，是防御性校验；但因库存为 0 而抛同一异常，就混淆了参数合法性与运行时状态
- 方法签名不暴露可能的“失败路径”，调用方无法从接口契约中感知业务约束
调试与维护成本陡增
异常堆栈容易淹没真实问题：当业务逻辑中混杂大量人为抛出的异常，日志里分不清是系统故障还是流程分支，排查时需反复确认“这到底是 bug 还是故意写的？”
立即学习“Java免费学习笔记（深入）”；
- 空 catch 或只写 e.printStackTrace() 会让问题静默失效，静态扫描工具（如 SonarQube）会直接标为严重漏洞
- 全局 catch(Exception e) 会吞掉 NullPointerException 等编程错误，导致缺陷延迟暴露
- 测试难度上升——要为每个“业务异常”写单独的 mock 和断言，而返回值或 Optional 更易验证
有更清晰、更可控的替代方案
把“可能失败”显式建模为返回值，让调用方自主决策，比隐式抛异常更符合面向对象与契约编程原则。
- 简单二值：用 Optional<Order> 表示创建成功或不存在
- 多状态分支：定义 enum OrderResult { SUCCESS, OUT_OF_STOCK, PAYMENT_FAILED }，方法直接返回枚举
- 携带上下文：封装 Result<T, E> 类，包含数据、错误码、提示信息，类似 Rust 的 Result 类型
- 预检先行：调用前先 checkUserPermission()、validateInput()，再执行核心逻辑
