java中处理受检异常的关键在于将其作为编译期风险契约，通过类型转换实现技术错误到业务语义的转译，依据调用方可否恢复决定保留或转为非受检异常，并辅以注解与文档显式表达契约。
Java中处理受检异常（Checked Exception）不能只靠“加try-catch”或“throws完事”，关键在于理解它为何存在、何时该用、以及如何通过类型转换让它更贴合业务语义。核心不是绕过检查机制，而是让异常成为清晰的契约表达。
受检异常的本质：编译期的风险契约
受检异常继承自Exception但不继承RuntimeException，典型如IOException、SQLException。编译器强制你面对——它提醒你：“这个操作依赖外部不确定性（文件、网络、数据库），你不处理，代码就通不过。”这不是限制，而是契约声明。
- 不要在每层都捕获后原样重抛，那只是机械应付编译器
- 不要把所有受检异常都转成RuntimeException来“简化”，这等于抹掉风险信号
- 真正需要的是在合适抽象层级上，把它翻译成业务可理解的失败原因
异常类型转换：从技术错误到业务语义
持久层抛出SQLException，服务层不该暴露SQL细节给调用方。这时要用异常转译（Exception Translation）：封装底层异常，抛出领域相关的业务异常。
- 例如：SQLException → UserRegistrationFailedException（含原始异常作为cause）
- 转换发生在技术边界处（如DAO → Service），保持各层关注点分离
- 保留原始异常栈信息，便于排查；但对外暴露的message应面向业务，不含SQL状态码或驱动名
什么时候该保留受检异常？什么时候该转为非受检？
判断依据不是“写起来麻不麻烦”，而是调用方是否能合理恢复：
- 保留受检异常：当失败可预期、有明确补救动作时。比如FileNotFoundException——调用方可选择提供默认配置、提示用户重选路径
- 转为非受检异常：当失败本质是编程错误或系统不可控故障。比如连接池耗尽导致的SQLException，此时更适合作为RuntimeException向上透传，触发兜底监控与告警
- 避免中间态：不要定义一个“既throws又catch”的方法，逻辑割裂且难以维护
配合注解与文档，让契约真正可见
仅靠编译检查不够。现代实践要求显式标注异常语义：
- 用@Throws（或Javadoc
@throws）说明每个公开方法可能抛出的受检异常及触发条件 - 对关键运行时异常（如IllegalArgumentException）也应在文档中标明校验逻辑，比如“当
userId 时抛出” - 结合Lombok的@NonNull或JSR-305注解，在参数层面提前拦截空值类异常，减少运行时崩溃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
