异常不是流程控制工具，受检异常尤其不适合驱动业务逻辑分支；它应标记“出错了无法继续”，而非表达“值不存在走另一条路”，真正可预测的分支应用if-else、状态机或策略模式实现。
异常不是流程控制工具，受检异常尤其不适合用来驱动业务逻辑分支。它本意是标记“出错了，当前无法继续”，而不是表达“这个值不存在，走另一条路”。把 IOException 或 SQLException 当作 if 条件用，既违背语义，也埋下隐患。
受检异常的定位很明确
受检异常（Checked Exception）是编译器强制你面对的外部不确定性——比如文件可能被删、数据库连接可能断开、网络请求可能超时。它们代表调用方有能力也有责任去响应的现实风险。但这种“可响应”，不等于“该用来决定下一步做什么”。
- 它适合做“兜底动作”：打开文件失败，提示用户重选路径；查询无结果，返回空列表并记录日志
- 它不适合做“主干判断”：用
catch FileNotFoundException来决定是否初始化默认配置，不如先Files.exists(path)判断再处理 - 强行用受检异常跳转，会让 try-catch 块膨胀成主逻辑，掩盖真正需要关注的业务规则
流程控制该由结构化语句承担
条件判断、状态机、策略模式这些机制天然支持可预测、可测试、可追踪的分支。而异常一旦介入，就引入了隐式跳转——你无法仅靠阅读代码顺序确认执行路径，必须结合 throw 点、catch 位置和调用栈才能还原逻辑。
- if-else 清晰表达“如果 A 成立，走 X；否则走 Y”
- try-catch 却暗示“假设 X 会成功，但如果它意外崩了，就跳去 Y 处理”——而很多所谓“意外”，其实是设计时就能预见的常态
- 例如检查用户权限：抛出
AccessDeniedException后在 catch 里跳转到登录页，不如直接if (!hasPermission()) { redirectToLogin(); return; }
性能与可维护性双重损耗
受检异常虽在编译期强制处理，但运行时开销并不小。每次抛出都要填充堆栈、展开调用帧，在高并发或高频路径上累积起来就是可观延迟。更麻烦的是，它让错误处理和正常逻辑耦合过紧。
- 一个本该只做校验的 service 方法，因用了异常控制流，不得不包裹多层 try-catch，还可能遗漏 finally 清理
- 日志中大量出现 “FileNotFoundException: config.properties (No such file or directory)” 并非系统故障，只是启动时缺配置——这会让真正的问题被淹没
- 单元测试需模拟各种异常场景，而本可通过简单输入覆盖的逻辑，变得复杂且脆弱
什么情况下可以破例？
极少数边界场景下，受检异常能简化设计，但前提是：它不替代判断，而是封装判断后的不可恢复后果。
- 第三方 SDK 强制抛出受检异常，且你无法预判其触发条件（如某些老版本 JDBC 驱动在特定 SQL 下才抛
SQLTimeoutException） - 统一网关层将多种底层异常归一为业务异常（如
PaymentFailedException），此时异常是结果封装，而非流程开关 - 资源初始化阶段，失败即终止进程（如 Spring 启动时加载核心配置失败），这时异常是终止信号，不是分支选择
