在 finally 块中执行 return 或抛出异常会覆盖 try/catch 中的返回值或异常；应避免在 finally 中写 return，优先使用 try-with-resources 管理资源，必须写逻辑时仅做无副作用操作且禁用 return/throw。
在 Java 中，finally 块中执行 return 或抛出异常，会覆盖 try 或 catch 中的返回值或异常——这是极易被忽略却后果严重的隐蔽 Bug。关键不是“能不能写”，而是“要不要写”以及“怎么写才安全”。
避免在 finally 中写 return 语句
finally 的本意是确保清理逻辑（如关闭资源、释放锁）一定执行，而非控制流程或返回结果。一旦在其中写 return，它会无条件覆盖前面所有分支的返回值：
-
try中return "ok"，finally中return "done"→ 实际返回"done"，且"ok"永远丢失 -
catch抛出IllegalArgumentException，finally中return 42→ 异常被静默吞掉，调用方收到 42，完全不知出错
资源清理优先用 try-with-resources，而非手动 finally
Java 7+ 推荐用 try-with-resources 自动管理 AutoCloseable 资源，彻底规避手写 finally 的风险：
- 无需显式
close()调用，更不会误加return - 即使
try块抛异常，资源仍被正确关闭，原异常不被覆盖（若close()也抛异常，则作为 suppressed exception 附加） - 示例：
try (FileInputStream fis = new FileInputStream("a.txt")) { ... }—— 安全、简洁、符合语义
必须在 finally 中做逻辑时，禁用 return 和 throw
若因历史原因或特殊场景（如日志记录、指标上报）必须在 finally 写代码，请严格遵守：
立即学习“Java免费学习笔记（深入）”；
- 只做副作用操作：打印日志、更新计数器、释放非关键锁等
- 绝不调用可能抛检查异常的方法（除非包裹在
try-catch中且不 re-throw） - 绝不写
return、throw、System.exit()等流程中断语句 - 若需传递状态，应通过外部变量或方法参数（如原子引用）间接影响，而非控制返回
用单元测试主动暴露这类 Bug
这类 Bug 很难靠肉眼发现，但极易通过测试验证：
- 为有
finally的方法编写多路径测试：正常返回、try抛异常、catch抛异常 - 断言实际返回值和抛出异常类型，而非只看是否成功
- 使用静态分析工具（如 SpotBugs）配置规则
RV_RETURN_VALUE_IGNORED_BAD_PRACTICE或BC_BAD_CAST_TO_ABSTRACT_COLLECTION（部分版本含 finally-return 检查）
