受检异常通过强制处理可恢复的外部不确定性来提升程序健壮性，但仅适用于io、网络等外部异常；滥用（如封装空指针）反而损害健壮性，需与非受检异常分工协作，并辅以上下文信息、资源管理和异常封装等实践。
受检异常（Checked Exception）与程序健壮性存在明确的正相关关系，但这种相关性并非自动成立，而是依赖于开发者是否将其用于“可恢复的外部不确定性”场景。
受检异常天然支撑健壮性设计
健壮性强调系统在面对不正常输入或外部异常环境时仍能合理响应、不崩溃、不静默失败。受检异常强制编译期检查，迫使调用方必须显式处理或声明传播——这直接杜绝了“忽略文件不存在”“跳过网络超时”等常见容错盲区。
- 文件读取失败（FileNotFoundException）→ 调用方可提示用户重选路径或加载默认配置
- 数据库连接中断（SQLException）→ 可触发重试机制或降级到缓存数据
- 网络请求超时（IOException）→ 允许切换备用服务地址或返回友好提示
关键前提：仅对“可恢复的外部异常”使用受检异常
若把本该由逻辑校验预防的错误（如空指针、非法参数）包装成受检异常，反而会削弱健壮性——它混淆了“环境不确定性”与“代码缺陷”的边界，导致调用方疲于应付本不该发生的流程分支。
- ✅ 合理：用户上传的XML文件格式错误 → 抛出 ParseException（受检），让上层提供修复指引
- ❌ 不当：私有方法传入 null 参数 → 不应抛受检异常，而应使用断言或 IllegalArgumentException（非受检）快速失败
与非受检异常形成分工协作
健壮性不是靠单一机制实现的。受检异常负责兜住外部不可控因素；非受检异常（RuntimeException子类）则守住内部正确性底线。二者配合，才能既对外宽容、又对内严格。
- 外部依赖失败（IO、网络、配置缺失）→ 受检异常 → 引导容错行为
- 内部状态不一致（集合为空却调用 get(0)、计算逻辑违反前置条件）→ 非受检异常 → 立即暴露 bug，避免错误蔓延
实践中的增强点
仅抛出受检异常还不够，需配套设计才能真正提升健壮性：
- 异常信息包含上下文（如具体文件名、SQL语句片段、HTTP状态码），便于定位和恢复
- 避免在 finally 块中覆盖原始异常（防止根因丢失）
- 结合 try-with-resources 自动释放资源，防止因异常导致句柄泄漏，间接维持系统稳定性
- 在 API 层统一转换底层受检异常为业务级异常（如将 SQLException 封装为 OrderPersistenceException），保持调用契约清晰
