健壮的 try-catch-finally 核心是精准捕获、明确处理、资源可控：只捕获可处理的特定异常（如 ioexception、sqlexception），避免通配捕获；finally 仅用于资源清理，优先使用 try-with-resources；重新抛出异常须保留 cause。
编写健壮的 try-catch-finally 结构，核心不是“多捕获”，而是“精准捕获、明确处理、资源可控”。重点在于区分异常类型、避免掩盖问题、确保资源释放，而非堆砌 catch 块。
只捕获你有能力处理的异常
不要用 Exception 或 Throwable 通配捕获——这会吞掉本该崩溃的编程错误（如 NullPointerException、ArrayIndexOutOfBoundsException）。真正需要捕获的是可预期、可恢复的受检异常（如 IOException、SQLException），或业务层面定义的自定义异常。
- 对文件读取操作，捕获 IOException 并重试或提示用户路径错误，而不是捕获 Exception 后静默失败
- 数据库查询失败时，捕获 SQLException 后检查连接状态并尝试重建连接，而非笼统地打印日志后继续执行
- 若 catch 块里只有 e.printStackTrace() 或空 catch，说明你其实没想好怎么处理，不如让上层决定
finally 中只做资源清理，不做业务逻辑
finally 的职责唯一且明确：释放资源。它会在 try 或 catch 执行完毕后无条件运行（除非 System.exit() 或 JVM 崩溃），但绝不适合放重试、日志上报或状态更新等可能抛异常的操作。
- 流、连接、锁等必须显式 close() 的资源，优先用 try-with-resources（Java 7+），它自动在 finally 隐式调用 close()
- 若手动管理，finally 中调用 close() 前务必判空，并用独立 try-catch 包裹 close() 本身，防止关闭异常干扰主流程
- 避免在 finally 中修改业务变量、调用远程接口或 throw 新异常——这会打乱原有控制流，甚至掩盖原始异常
利用 try-with-resources 替代手写 finally
对于实现了 AutoCloseable 接口的资源（如 FileInputStream、Connection、Scanner），try-with-resources 是更安全、更简洁的选择。它保证资源在语句结束时自动关闭，无论是否发生异常。
- 语法形如：try (FileInputStream fis = new FileInputStream("a.txt")) { ... }，fis 会在 } 处自动 close()
- 多个资源可用分号分隔，关闭顺序与声明顺序相反（后声明先关闭），符合资源依赖关系
- 若关闭过程抛出异常，它会被抑制（suppressed）并附加到主异常上，可通过 getSuppressed() 查看，不丢失上下文
catch 后重新抛出时，慎用 throw e 而要 throw new XxxException(..., e)
直接 throw e 会丢失当前调用栈信息；而 throw new RuntimeException("业务操作失败", e) 可保留原始异常作为 cause，同时提供更清晰的上下文描述，便于排查。
- 在 service 层捕获 DAO 层的 SQLException，应包装为 ServiceException 并传入原始异常，而不是原样 re-throw
- 若需改变异常类型（如将受检异常转为运行时异常），务必保留 cause，否则堆栈中看不到底层根因
- 不要在 catch 里吞掉异常又 log.warn("忽略异常")——这会让问题在生产环境悄无声息地腐烂
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
