合理嵌套try-catch-finally应服务于分层异常处理：外层关注业务流程成败与资源收尾，内层专注子步骤容错与局部恢复，严格遵循职责分离、资源独管、类型匹配原则，并优先使用try-with-resources替代嵌套finally。
Java 中的 try-catch-finally 嵌套不是语法强制要求，而是业务复杂度上升后的自然选择。关键不在于“能不能嵌套”，而在于“该不该嵌套”以及“怎么嵌套才清晰、安全、可维护”。合理嵌套能分层隔离异常影响范围，避免顶层 catch 捕获过宽；不合理嵌套则会导致逻辑混乱、资源重复释放、finally 执行顺序难控等问题。
嵌套前先判断是否真有必要
多数场景下，单层 try-catch-finally 已足够。嵌套应服务于明确目的：
- 外层关注业务流程整体成败（如“下单失败需回滚订单”），内层专注某子步骤的细节容错（如“调用库存服务超时，降级查本地缓存”）
- 不同层级需要不同处理策略：外层记录告警并返回用户提示，内层重试或切换备用路径
- 资源作用域不同：外层管理数据库连接，内层管理临时文件流，各自在对应 finally 中关闭
- 异常类型差异大：外层捕获 RuntimeException 表示系统级故障，内层捕获 IOException 只做局部补偿
嵌套结构要严格遵循“职责分离”原则
避免把所有逻辑塞进一个 try 块再层层 catch。推荐按执行阶段切分：
- 外层 try：包裹整个业务主干，catch 处理流程级异常（如 ServiceUnavailableException），finally 保证事务/连接收尾
- 内层 try：仅包裹易出错且可独立恢复的子操作（如 HTTP 调用、JSON 解析），catch 后可返回默认值或抛出自定义业务异常
- 绝不让内层 finally 关闭外层已声明的资源（如内层 close() 了 connection，外层再 close 就报错）
- 若内层有 return，外层 finally 仍会执行——这点必须写进注释，避免被误认为“提前退出”
资源释放优先用 try-with-resources，而非嵌套 finally
嵌套 finally 容易引发资源关闭顺序错误或重复关闭。Java 7+ 推荐用 try-with-resources 替代手工管理：
立即学习“Java免费学习笔记（深入）”；
- 每个资源声明为 final 或 effectively final，自动按声明逆序关闭
- 即使 try 块抛出异常，所有资源仍保证关闭，close() 抛出的异常会被压制（suppressed）并附在主异常上
- 多资源嵌套更清晰：外层用 try-with-resources 管理 DB 连接，内层用另一个 try-with-resources 管理 ResultSet，无需手写嵌套 finally
- 若必须嵌套 finally（如旧版 JDK 或非 AutoCloseable 对象），确保每个 finally 只关自己负责的资源，并判空再 close()
嵌套中 return 和 finally 的执行顺序要心里有数
这是最容易踩坑的点。记住三条铁律：
- 无论 try 或任意 catch 中是否有 return，对应的 finally 必定执行（除非 JVM 直接退出或线程被 kill）
- 如果 finally 里也有 return，它会覆盖 try/catch 中的返回值——这种写法禁止出现
- 嵌套时，内层 finally 在内层 return 之后、外层 return 之前执行；外层 finally 在外层 return 之后执行
- 建议在 finally 中只做释放、清理、日志等副作用操作，绝不修改返回值或抛出新异常
