Java中受检异常应限于“可预见、可恢复、调用方知情”场景，如SDK接口IO失败、批处理单条解析错误、配置加载格式异常；其余情况优先用运行时异常、资源自动管理及统一异常处理机制。
Java中受检异常（Checked Exception）曾是语言稳健性的核心设计，但它的强制性在现代开发中逐渐暴露出适配性问题。当前主流方案不是彻底弃用，而是精准控制使用范围，并配合运行时异常、资源自动管理与框架级统一处理来实现更自然、可维护的错误应对。
受检异常的设计初衷与现实落差
受检异常要求编译期必须显式处理（try-catch 或 throws），本意是让开发者直面可恢复的外部故障，比如文件读取失败（IOException）、数据库连接中断（SQLException）。但实践中常出现以下情况：
- 调用方无法真正恢复，只能包装后重抛，导致异常层层传递、语义模糊
- 为通过编译而写空 catch 块或仅打印日志，掩盖真实问题
- 接口因底层变更被迫增加 throws 声明，破坏契约稳定性
现代项目中受检异常的合理定位
它不再被当作“默认选项”，而是有明确边界的工具：
- 仅用于调用者有能力且应当介入恢复的场景，例如：网络请求超时后自动重试、文件不存在时创建默认配置
- 避免在服务层、业务逻辑层暴露受检异常；DAO 层若使用 Spring，
SQLException会被自动转为DataAccessException（RuntimeException 子类） - 自定义业务异常优先继承
RuntimeException，除非该异常明确需要强制下游做补偿操作
替代与增强机制已成标配
单纯依赖受检异常已不够，成熟项目普遍组合使用以下技术：
立即学习“Java免费学习笔记（深入）”；
-
Try-with-resources：自动释放
AutoCloseable资源，消除因手动 close 遗漏导致的资源泄漏，也减少了围绕 IOException 的冗余 finally 块 -
@Transactional：Spring 中事务回滚默认响应 RuntimeException，若需对某受检异常回滚，显式配置
rollbackFor = MyCheckedException.class - @ControllerAdvice + @ExceptionHandler：在 Web 层统一捕获并转换异常，返回结构化错误响应，屏蔽底层异常类型细节
-
异常链保留：用
new ServiceException("下单失败", e)包装原始异常，确保根本原因不丢失
何时仍应坚持使用受检异常
并非完全淘汰，关键看是否满足“可预见 + 可恢复 + 调用方知情”三要素：
- 公共 SDK 接口，使用者需明确知道可能遇到 IO 或解析失败，并自行决定重试或降级
- 批处理任务中，单条记录失败不应中断整个流程，此时
ParseException作为受检异常，便于调用方逐条捕获处理 - 配置加载模块，若配置文件格式错误，抛出
ConfigurationException（受检）比静默失败或抛 NPE 更利于排查
