多层try-catch并非嵌套越多越好，应按异常类型粒度、恢复策略和资源生命周期分段设计；捕获顺序须从具体到宽泛，避免子类异常被父类吞没；推荐使用try-with-resources确保资源安全关闭，并合理处理suppressed异常。
多层try-catch不是嵌套越多越好
Java里写多层 try-catch，常见误区是把多个业务逻辑块硬塞进层层嵌套的 try 块里，结果导致异常流向混乱、资源泄漏风险上升、可读性暴跌。真正需要“多层”的场景，其实是**异常类型粒度不同、恢复策略分离、或资源生命周期分段管理**——比如外层捕获通用业务异常做降级，内层捕获具体IO异常做重试或清理。
按异常层级顺序捕获，否则子类会被父类吞掉
Java异常是树状继承结构，Exception 是顶层，IOException、SQLException 等是其子类。如果 catch 块顺序写反，比如先写 catch (Exception e) 再写 catch (IOException e)，后者永远执行不到，编译器直接报错 Unreachable catch block。
正确顺序必须从具体到宽泛：
try {
readFile();
} catch (FileNotFoundException e) {
// 先处理最具体的
log.warn("配置文件不存在，使用默认值");
} catch (IOException e) {
// 再处理父类
throw new ServiceException("读取配置失败", e);
} catch (Exception e) {
// 最后兜底（慎用）
log.error("未知异常", e);
}
try-with-resources + 多层catch比手动close更安全
涉及流、连接、通道等资源时，很多人用传统多层 try 套 finally 关闭，但容易漏掉 close() 异常覆盖主异常（即所谓“异常屏蔽”）。用 try-with-resources 能自动关闭且保留原始异常。
立即学习“Java免费学习笔记（深入）”；
搭配多层 catch 时注意：
-
try-with-resources的资源声明部分不能抛出检查异常，需在内部处理或包装 - 资源关闭时抛出的异常会作为 suppressed exception 附加到主异常上，可通过
e.getSuppressed()查看 - 若需对关闭异常单独响应（如记录、告警），得在
catch块里显式调用resource.close()并捕获，但这会失去自动管理优势
推荐写法：
try (FileInputStream fis = new FileInputStream("config.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
String line = reader.readLine();
process(line);
} catch (FileNotFoundException e) {
// 文件根本没找到
fallbackToDefaultConfig();
} catch (IOException e) {
// 读取过程出错（如磁盘满、编码异常）
retryWithBackupSource();
}
不要用多层catch掩盖设计缺陷
频繁出现“外层捕获所有异常→打印日志→继续执行”，或者“每层都 catch (Exception e) 后吞掉”，往往说明接口职责不清、异常分类缺失、或错误处理策略未收敛。比如数据库操作抛出 SQLException，本该由 DAO 层转换为领域异常（如 UserNotFoundException），而不是一路向上扔给 Controller 层用通用 catch 拦截。
复杂异常流程真正难的不是语法嵌套，而是：
- 哪些异常该被当前层捕获并恢复（如网络超时重试）
- 哪些必须向上透传（如数据校验失败应由调用方决定是否重试）
- 哪些该转成新异常并保留原始根因（用
new XxxException("msg", cause)） - 日志级别是否匹配异常严重程度（
WARNvsERROR）
这些判断点，比写几个 try 块关键得多。
