finally中抛异常会覆盖原始异常，必须用内层try-catch处理清理逻辑；禁用throw和return；优先使用try-with-resources；空值校验、日志记录、锁状态检查缺一不可。
finally块中抛出异常会直接覆盖try或catch里的原始异常，导致错误根源丢失；预防核心是不让清理逻辑干扰主流程——不抛异常、不写return、不掩盖错误。
避免finally中主动抛出异常
资源关闭（如close()）失败时若直接throw，会抹掉业务层已发生的NullPointerException或SQLException。原始异常被JVM丢弃，调用方只能看到“关闭失败”，无法定位真正问题。
- 对可能失败的清理操作加内层try-catch：例如
try { fis.close(); } catch (IOException e) { logger.warn("流关闭异常", e); } - 禁止在finally中使用
throw语句，哪怕逻辑上“必须报错”——这类判断应移到catch末尾或单独校验方法中 - 特别注意旧式JDBC代码：关闭Connection前未判空、手动调用shutdown()等易触发IO异常的操作
用try-with-resources替代手写finally
Java 7+推荐方式，编译器自动生成资源关闭逻辑，并原生支持异常抑制机制：主异常保留为抛出主体，清理异常作为suppressed exception附加其上。
- 资源类型需实现
AutoCloseable（InputStream、Connection、Scanner等均满足） - 示例：
try (FileInputStream fis = new FileInputStream("a.txt")) { /* 业务逻辑 */ }，即使read()抛RuntimeException且close()抛IOException，前者仍是主异常 - 可通过
e.getSuppressed()获取被抑制的异常，调试时完整还原上下文
禁止finally中出现return语句
finally里的return会强制终止方法，覆盖try/catch中已计算好的返回值或吞掉正在传播的异常——这不是bug，而是JVM明确规定的执行优先级。
- 正确做法：用局部变量暂存结果，所有return统一放在finally之外，例如
int result = -1; try { result = compute(); } catch (Exception e) { result = DEFAULT; } finally { cleanup(); } return result; - 启用
-Xlint:finally编译选项或Checkstyle规则，在编译期拦截finally中的return/throw - 团队规范中明确禁止在finally块内做流程控制，只允许无副作用的清理动作
关键清理操作的安全写法
高频踩坑点集中在资源释放环节，需逐项检查是否做了防御性处理：
- 流/连接关闭前先判空：
if (fis != null) try { fis.close(); } catch (IOException e) { /* 记录日志 */ } - 自定义release方法内部含网络IO时，同样需包裹try-catch，且不向外传播
- 日志框架flush()或shutdown()放在finally时，捕获InterruptedException并标记为已处理，不重抛
- 锁释放（如ReentrantLock.unlock()）虽不抛检查异常，但需确保仅在已加锁状态下调用，避免IllegalMonitorStateException
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
