受检异常应仅用于调用方有能力且应当介入恢复的场景，需语义明确、边界合理、上下文清晰，并通过测试验证恢复路径。
受检异常（Checked Exception）在 Java 中是编译器强制要求处理的异常类型，它直接关联到程序对外部环境变化的响应能力。其健壮性不在于“是否抛出”，而在于是否让调用方具备可操作的恢复路径；其可维护性也不取决于声明了多少 throws，而在于异常语义是否清晰、边界是否合理、处理逻辑是否可追踪。
明确异常的恢复责任归属
受检异常应仅用于调用者**有能力且应当介入恢复**的场景。例如：
-
文件不存在（
FileNotFoundException）：调用方可提示用户重选路径、创建默认配置或切换备用资源； -
网络连接超时（
SocketTimeoutException）：调用方可执行重试、降级为缓存数据或返回友好提示； -
数据库连接失败（
SQLException）：若发生在初始化阶段，应向上抛出并中止启动；若发生在业务查询中，需结合事务状态决定回滚或补偿。
若异常发生后调用方唯一能做的只是记录日志并退出，那它就不该是受检异常——此时应包装为非受检异常（如自定义 UnrecoverableSystemException），避免强制处理带来的虚假安全感。
避免异常泛化与语义模糊
一个方法声明 throws Exception 或 throws IOException（却实际可能因参数校验失败而抛出）会严重损害可维护性：
- 调用方无法区分“磁盘满”和“路径为空”这两种完全不同的修复策略；
- 新增一种失败原因（如权限不足）时，若复用已有异常类型，会导致下游处理逻辑误判；
- 建议为每类可恢复错误定义语义明确的子异常，例如：
ConfigLoadFailureException、NetworkUnreachableException，并在 Javadoc 中说明每种异常对应的恢复建议。
统一异常转化与上下文增强
底层 API（如 JDBC、NIO）抛出的原始受检异常往往缺乏业务上下文，直接暴露会给上层处理带来困难：
- 在 DAO 层捕获
SQLException后，不应简单throw new RuntimeException(e)，而应转化为带业务标识的受检异常，例如：OrderPersistenceException("Failed to save order #"+orderId, e)； - 在 service 层接收该异常时，可结合当前用户 ID、请求 ID、操作类型等注入上下文字段，便于日志追踪与监控告警；
- 避免在多层之间重复包装同一异常，推荐采用“一次转化、逐层追加上下文”的策略，保持堆栈完整性的同时提升可读性。
测试驱动异常路径覆盖
健壮性不能靠代码审查保证，必须通过可重复的测试验证：
- 对每个声明的受检异常，编写至少一个单元测试，模拟对应失败场景（如 mock 文件系统返回
ENOENT）； - 验证调用方是否执行了预期恢复动作（如重试次数、降级结果、错误提示文案）；
- 使用静态分析工具（如 ErrorProne）检查空 catch 块、忽略返回值、未记录异常等反模式。
