代码评审中try-catch-finally需确保资源释放兜底（优先try-with-resources）、catch不吞异常（须记录堆栈、分层捕获）、finally无副作用（禁return、避免异常穿透）、try块最小化（仅包裹风险代码）。
代码评审中，try-catch-finally不是“写上了就过关”的语法装饰，而是稳定性与可维护性的关键防线。重点不在是否用了，而在是否用对、用稳、用得干净。
资源释放是否真正兜底
常见问题：流、连接、锁等资源在 try 中打开，却未在 finally 中安全关闭；或 finally 里调用 close() 时没做判空/异常捕获，导致二次异常掩盖原异常。
- 检查 finally 块是否包含
if (resource != null) resource.close()或更稳妥的 try-catch 包裹 - 优先推荐 Java 7+ 的 try-with-resources（自动资源管理），它比手写 finally 更可靠、更简洁
- 若仍用手动释放，确认 close() 调用后不修改资源引用，避免后续误用
catch 块是否“吞异常”或过度宽泛
空 catch（catch(Exception e) {}）或仅打印日志却不记录堆栈、不告警、不重试/降级，等于把故障藏起来。
- catch 中必须至少记录异常完整堆栈（
e.printStackTrace()或log.error("msg", e)） - 避免用
Exception或Throwable捕获所有异常；按需分层捕获，如先捕FileNotFoundException，再捕IOException - 业务逻辑型异常（如参数校验失败）通常不应进 catch，而应提前防御或抛受检异常明确语义
finally 是否引入副作用或破坏返回值
finally 里写 return、修改返回变量、抛出新异常，会扰乱控制流，掩盖真实错误，是高危操作。
- 禁止在 finally 中出现
return语句——它会覆盖 try/catch 中已确定的返回值 - 避免在 finally 中修改基本类型返回变量（如
i = 5;），虽不改变返回值，但易引发理解偏差 - finally 中若调用可能抛异常的方法（如 close()），必须用内层 try-catch 包裹，防止异常穿透中断清理流程
结构是否精简且职责清晰
一个 try 块里塞入 20 行混合逻辑（IO + 计算 + DB + HTTP），会让异常定位困难，也违背“监控区只放风险代码”的原则。
- try 块应只包裹真正可能抛异常的最小代码段（如单次 read()、executeQuery()）
- 计算、转换、组装等非 IO/非外部依赖逻辑，移出 try，避免无谓捕获
- 多个独立资源操作（如先读文件、再连 DB），建议拆分为多个 try-with-resources 或独立 try-catch，降低耦合
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
