应拆分职责、用try-with-resources替代手动finally、按语义分层catch、finally仅做无副作用清理。例如将网络请求、JSON解析、数据入库分别封装，各处理自身异常；资源实现AutoCloseable时优先使用try-with-resources；catch按业务或技术目的分层，子类异常声明在父类前；finally中不return、不throw，仅执行close等清理操作。
多层嵌套的 try-catch-finally 容易让逻辑缠绕、缩进过深、异常流向模糊，但真正影响可读性与完整性的，不是嵌套本身，而是职责是否清晰、资源是否可控、异常是否被合理分流。
拆分逻辑，避免“一层包全局”
把不同责任的代码分离到独立方法中，比在同一个方法里堆叠多层 try 更清晰。比如网络请求 + JSON 解析 + 数据入库，每步都可能抛不同异常，与其全塞进一个 try 块，不如：
- 单独封装 fetchData()：专注处理连接超时、IO 异常，抛出受检业务异常（如
NetworkException） - 单独封装 parseJson()：捕获
JSONException并转为统一错误码，不向上透传原始异常 - 单独封装 saveToDB()：用 try-with-resources 管理 Connection/PreparedStatement，只在 catch 中回滚事务
这样每段代码只关心自己的异常边界，调用方只需处理聚合后的业务异常，嵌套自然消失。
用 try-with-resources 替代手写 finally 资源管理
传统嵌套中，多个流或连接的手动关闭常导致 finally 里堆满判空 + 嵌套 try-catch，既冗长又容易掩盖主逻辑。只要资源实现 AutoCloseable（如 FileInputStream、Connection、BufferedReader），就直接用：
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
String line = reader.readLine();
// 业务逻辑
} catch (FileNotFoundException e) {
// 处理文件不存在
} catch (IOException e) {
// 处理读取异常
}
资源自动关闭，无需 finally；异常不会被 close() 覆盖（Java 7+ 支持 suppressed exception）；代码行数减少，缩进扁平化。
catch 块按异常语义分层，不按技术层级堆叠
嵌套常见误区是“外层 catch Exception，内层再 catch 具体异常”，这反而破坏了异常分类价值。正确做法是：
-
外层 catch 关注业务结果：比如服务方法最终 catch
BusinessException，统一返回 HTTP 500 + 错误码 -
内层 catch 关注技术恢复：比如重试逻辑里，catch
SocketTimeoutException后 sleep 再重试，不向外抛 -
子类异常永远写在父类前面：例如
catch (SQLException e)必须在catch (Exception e)之前，否则后者会拦截前者
这样每一层 catch 都有明确目的，而不是为了“兜底而兜底”。
finally 只做一件事：清理，且绝不 return 或 throw
嵌套中 finally 最易出错——它若写 return，会覆盖 try/catch 的返回值；若抛新异常，会吞掉原始异常（比如数据库连接失败的真实原因）。所以：
- finally 里只放 close()、unlock()、remove() 这类无副作用的清理动作
- 绝对不写
return，也不主动throw新异常 - 如果清理动作本身可能异常（如 close() 抛 IOException），用 try-catch 包裹并仅记录日志，不打断主流程
资源释放交给 try-with-resources，finally 就真正回归“兜底清理”的本职。
