finally块中return会覆盖try/catch抛出的异常，导致异常静默丢失；应仅用于资源清理，避免return、throw或System.exit()。
在 finally 块中使用 return 语句会覆盖 try 或 catch 中抛出的异常，导致异常被静默丢弃——这是 Java（及类似语言）中一个经典且隐蔽的陷阱。排查这类问题，关键在于识别“本该抛出却没出现”的异常，以及理解控制流如何被 finally 中的 return 扰乱。
观察异常是否“消失”了
这是最直接的线索：代码逻辑上应抛出异常（比如空指针、IO 错误、自定义业务异常），但实际运行时既没报错，也没按预期进入错误处理分支，而是“意外”返回了某个值或正常结束。
- 检查日志——异常堆栈是否完全缺失？尤其注意本该记录异常的地方（如
catch块里的log.error(..., e)）是否根本没执行 - 调试时在
try块末尾或catch块中设断点，确认异常确实被抛出；再在finally块的return处设断点，看它是否被执行并提前终止方法 - 用 IDE 的“异常断点”（如 IntelliJ 的 Java Exception Breakpoint）捕获未处理异常，若该断点从未触发，而程序又返回了非预期结果，就高度可疑
审查 finally 块中的 return 或 throw
finally 块的本职是资源清理，不是控制返回逻辑。任何 return、throw 或 System.exit() 都会中断原有异常传播链。
- 逐行检查所有
finally块，重点找：return xxx;、throw new XxxException();、甚至看似无害的return;（void 方法） - 注意嵌套结构：外层 try-catch-finally 中的 finally，也可能被内层 finally 干扰
- 警惕“伪安全”写法，例如：
finally { if (resource != null) resource.close(); return result; }
即使close()抛异常，后面的return仍会压制它
用最小可复现代码验证怀疑
把疑似有问题的方法抽出来，构造一个极简测试用例，强制触发异常，观察行为：
- 示例（Java）：
static String test() {<br> try {<br> throw new RuntimeException("original");<br> } catch (Exception e) {<br> System.out.println("caught!");<br> throw e;<br> } finally {<br> return "from finally"; // ← 这行让 original 异常彻底消失<br> }<br> }
运行后输出只有"from finally"，无任何异常，"caught!"也不会打印 - 对比去掉
finally中的return，异常即可正常抛出
修复原则：finally 只做清理，不干预流程
真正安全的做法是让 finally 专注释放资源，把返回值和异常处理交给 try/catch 主干。
- ✅ 正确方式：
String result = null;<br> try {<br> result = doSomething();<br> } finally {<br> cleanup(); // 不 throw、不 return<br> }<br> return result; - ✅ 若清理过程可能失败且需反馈，应在
try或catch中显式处理，或封装为独立方法并声明异常，而非塞进finally - ⚠️ 替代方案（慎用）：JDK 7+ 推荐使用 try-with-resources，自动管理资源且不会干扰异常传播
