Java多层异常嵌套需分层有据、捕获有界、传递有逻辑：外层管业务成败与资源收尾，内层专责子步骤容错；捕获类型须具体且子类优先；内层异常应明确上抛或处理，避免吞异常或丢堆栈；资源管理首选try-with-resources。

Java 中多层异常嵌套不是写得越多越好，关键在分层有依据、捕获有边界、传递有逻辑。

按职责划分嵌套层级

外层关注业务成败与资源收尾，内层专注子步骤容错与局部恢复。比如：

• 外层 try 包裹整个下单流程，catch 处理 ServiceUnavailableException 做降级或告警，finally 确保事务回滚或连接关闭
• 内层 try 仅包裹调用库存服务这一步，catch TimeoutException 后可切换本地缓存，或重试两次
• 避免把读文件、解析 JSON、更新 DB 全塞进同一个 try 块再层层 catch——职责混杂，异常流向难追溯

捕获类型必须具体且顺序合理

不能笼统 catch (Exception e)，更不能让父类异常先于子类出现：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 正确顺序：先 catch SQLException，再 catch IOException，最后才是 Exception（如有兜底需要）
• 错误写法：catch (Exception e) 放在最前 → 后面所有具体异常都匹配不到，直接被吞掉
• 像 RemoteServiceException 和 DuplicateKeyException 这类业务相关异常，应单独捕获并做差异化处理（前者抛出提示重试，后者直接忽略）

内层异常不“吃掉”，要明确传递意图

内层 catch 不是终点站，而是中转站——是否上抛，得由你决定：

立即学习“Java免费学习笔记（深入）”；

• 如果异常已就地解决（如幂等重复写入），不 throw 是合理选择，外层无需感知
• 如果需交由上层统一兜底（如记录日志、返回用户提示），必须显式 throw e 或 throw new BizException("xxx", e)
• 切忌在 catch 里 new 一个全新异常（如 throw new RuntimeException("出错了")）→ 原始堆栈和根因信息全丢，排查变困难

资源管理优先用 try-with-resources，少用手动嵌套 finally

嵌套 finally 容易引发重复关闭、空指针或顺序错乱：

• 数据库连接 + ResultSet 场景：外层用 try (Connection conn = ...)，内层另起 try (ResultSet rs = ...)，各自自动关闭
• 若必须手写 finally（如老版本 JDK 或非 AutoCloseable 对象），每个 finally 只关自己负责的资源，并加 if (res != null) res.close()
• 多个资源声明时，try-with-resources 按逆序关闭，还能把 close() 抛出的异常作为 suppressed exception 附在主异常上，不丢失上下文