推荐做法是分层解耦异常处理：底层抛具体受检异常，中间层适配包装，顶层统一响应；用自定义 throwingfunction 接口及 uncheck() 工具支持 lambda；优先 try-with-resources 管理资源；统一在 controlleradvice 中转换异常；捕获包装异常时须显式展开 cause 链。
受检异常的嵌套捕获本身不是推荐做法——真正需要的是避免层层 try-catch 堆叠，同时不丢失异常语义。关键在于分层解耦：底层专注抛出具体受检异常，中间层做适配或包装，顶层统一响应。优雅不等于“藏起来”，而是让异常流动得清晰、可控、可追溯。
用自定义函数式接口承接受检异常
标准函数式接口（如 Supplier、Consumer）无法声明 throws，导致 Lambda 内必须硬套 try-catch。解决办法是定义带异常声明的接口，并提供轻量转换工具：
- 声明 @FunctionalInterface public interface ThrowingFunction
{ R apply(T t) throws E; } - 配套工具方法 uncheck() 将其转为无异常声明的标准接口，内部用 RuntimeException 包装，但保留原始 cause
- 这样既维持 Lambda 表达式简洁性，又确保异常栈信息不丢失，调试时仍能定位到原始 IOException 或 SQLException
资源管理优先用 try-with-resources，而非嵌套 try
多层 IO 或 JDBC 操作容易形成嵌套 try，比如先开 FileInputStream，再套 BufferedReader，再套 InputStreamReader。这既难读又易漏关闭。
- 改用单层 try-with-resources：try (var fis = new FileInputStream("a.txt"); var br = new BufferedReader(new InputStreamReader(fis))) { ... }
- 所有资源自动按逆序 close，无需手动 finally，也不用嵌套 try 块
- 若某资源关闭时也抛异常（如 flush 失败），它会被抑制（suppressed），可通过 e.getSuppressed() 查看，不影响主异常传播
统一异常转换层，避免中间层重复捕获
Service 层调用 DAO，DAO 抛出 SQLException；Controller 调用 Service，又得 catch 一次——这不是健壮，是冗余。
- DAO 层直接抛出原始受检异常，或包装为更语义化的业务异常（如 DataAccessException），并传入 cause
- 在 Spring 等框架中，用 @ControllerAdvice + @ExceptionHandler 在最外层集中拦截，转成 HTTP 状态码和用户提示
- 中间 Service 层只关注业务逻辑，不写任何 try-catch，异常自然向上冒泡，职责分明
嵌套异常要显式展开，而不是静默吞掉
有时上层捕获的是包装异常（如 ExecutionException），真实原因藏在 cause 里。忽略 getCause() 就等于放弃根因。
- 捕获后第一件事是检查 e.getCause()，尤其当异常类型是 ExecutionException、InvocationTargetException 等典型包装类时
- 日志中应打印完整链路：log.error("操作失败", e);（SLF4J 默认输出 cause 链）
- 必要时递归遍历 cause，提取最内层业务相关异常（比如从三层包装中取出原始 SQLException 的 SQLState）用于决策
