java中应避免受检异常向上穿透调用链，宜在源头包装为运行时异常、通过抽象层隔离、用optional替代异常控制流，并谨慎保留真正需调用方恢复的受检异常。
Java中受检异常（Checked Exception）要求方法必须显式声明或捕获，一旦底层方法抛出新的受检异常，调用链上所有中间方法都得修改——加throws声明或try-catch，容易引发“异常传染”，破坏封装、增加维护成本。解决核心是：**不让受检异常向上穿透调用链，而是尽早转换、封装或规避**。
用运行时异常包装受检异常
将受检异常转为RuntimeException子类（如IllegalArgumentException、自定义异常），绕过编译检查。这是最常用且符合实践的做法。
- 在最靠近异常源头的位置捕获受检异常，立即包装并抛出运行时异常
- 避免在工具类或底层API中直接抛出运行时异常，应保留原始异常作为cause，便于排查
- 示例：
throw new RuntimeException("读取配置失败", e);
抽象层统一处理，隔离异常细节
在业务逻辑与底层实现之间加一层适配（如DAO接口、Service门面），让上层只依赖抽象契约，不感知具体异常类型。
- DAO接口方法声明抛出自定义的业务异常（如
DataAccessException，继承RuntimeException） - 实现类内部处理JDBC/IO等受检异常，统一转换后抛出
- 上层Service调用DAO时无需声明throws，也不用写冗余catch
用Optional或结果容器替代异常控制流
对预期可能失败的操作（如查找、解析、转换），改用Optional、Result<t e></t>（如vavr或自定义）封装成功/失败状态，把“异常”变成数据的一部分。
- 适合非错误场景下的可选性（如缓存未命中、配置不存在）
- 避免用异常表示正常业务分支（如“用户不存在”不是程序错误，不该抛
UserNotFoundException受检异常） - 调用方通过
isPresent()或map()/orElse()处理，逻辑更清晰
谨慎选择是否保留受检异常
并非所有受检异常都该被消灭。只有当调用方**无法合理恢复**时，强制声明反而增加负担；若确实需要调用方决策（如网络超时、文件权限不足），保留并明确命名更有意义。
- 评估异常是否属于“外部可恢复条件”：如果是，保留受检异常并提供重试、降级、提示等上下文
- 避免泛化使用
Exception或IOException，优先定义语义明确的异常类型 - 团队内约定：基础模块（IO、DB、HTTP客户端）可抛受检异常；业务模块对外接口统一用运行时异常
不复杂但容易忽略的是：异常策略要从架构初期就定好，而不是等改到第十个方法时才意识到问题。关键是让异常传递路径变短、语义变明确、调用方负担变轻。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
