finally块不应包含return、throw或System.exit()，其唯一职责是资源清理；异常消失或返回值被篡改时，应优先检查finally中是否误写return等语句。
finally 块本该稳如磐石，却常因几行代码让异常“凭空消失”、返回值“偷偷被换”。问题核心就一条：finally 不是控制出口的地方，而是清理现场的收尾人。写错它，轻则逻辑错乱，重则故障难定位。
异常突然“没了”，先盯 finally 里的 return
程序本该抛出 NullPointerException 或自定义业务异常，结果却静默返回一个字符串或数字——这是最典型的信号。重点检查：
- 所有 finally 块中是否写了
return、throw或System.exit() - 哪怕只是
return;（void 方法），也会中断异常传播链 - 嵌套 try-catch-finally 中，外层 finally 的 return 会覆盖内层 catch 抛出的异常
资源关闭写在 finally，但别让它“带病上岗”
常见错误是直接调用未初始化对象的方法，比如：
- try 中 new FileReader 失败 → reader 为 null → finally 中调用 reader.close() → 触发新的 NullPointerException
- 修复方式：加判空，或更推荐用 try-with-resources（Java 7+），自动处理初始化与关闭
调试时别只看结果，要看“谁真正执行了”
光看方法返回值容易误判。建议：
立即学习“Java免费学习笔记（深入）”；
- 在 try 块末尾和 catch 块 throw 处设断点，确认异常确实生成并准备抛出
- 在 finally 的 return 行再设断点，观察它是否被执行、是否提前终结方法
- 启用 IDE 的“Exception Breakpoint”，捕获未处理异常；若该断点从不触发，而方法又返回了意外值，基本可锁定问题
修复不是删掉 finally，而是回归它的本职
finally 的唯一使命是清理：关流、释放连接、解锁、清状态。其他事交给 try 和 catch：
- 返回值统一放在方法末尾，不在 try/catch/finally 中多次 return
- 异常处理逻辑写在 catch 块里，不要指望 finally 捕获或重抛
- 若需在清理后返回默认值，应明确设计成“兜底逻辑”，而非依赖 finally 的 return 覆盖异常
