finally的核心价值是确保关键清理动作无条件执行，需提前声明资源变量、判空并捕获close异常，优先使用try-with-resources，且finally仅用于资源释放。

finally 的核心价值不是“兜底执行”，而是确保关键清理动作无条件发生——哪怕 try 抛异常、catch 里 return，甚至 catch 再抛新异常，它依然会运行。

资源变量必须提前声明

如果把文件流、临时文件对象等在 try 块内 new 出来，一旦构造过程出错（比如路径非法、磁盘满），变量根本没被初始化，finally 就无法访问它。正确做法是：在 try 外声明为 null，再在 try 内赋值。

• 声明写在 try 前：FileInputStream fis = null; 或 File tempFile = null;
• 避免在 try 内直接声明并初始化，否则 finally 会报编译错误或空指针
• 对临时文件，推荐用 Path tempPath = Files.createTempFile(...)，再传给 finally 处理

finally 中关闭资源要加判空和异常捕获

close() 方法本身可能失败（如网络中断、权限不足），若不处理，反而会在 finally 里抛出新异常，掩盖原始错误。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 先判断资源是否非 null，再调用 close()
• close() 要套一层 try-catch，异常可记录日志或忽略，但不能向上抛
• 不要写 fis.close(); 这种裸调用，也不要用 throw e; 替代 throw;，以免破坏堆栈追踪

优先用 try-with-resources 替代手动 finally

Java 7+ 提供的 try-with-resources 是更安全、简洁的替代方案，适用于实现了 AutoCloseable 的资源（如 InputStream、Connection、Scanner）。

• 资源在 try 括号内声明，自动在退出时调用 close()
• 即使 try 中抛异常，close() 仍会执行；多个资源按逆序关闭
• 若 close() 抛异常，会被“压制”（suppressed），主异常仍保留，可通过 getSuppressed() 查看

finally 不是日志打印区，更不是逻辑兜底处

它的职责非常单一：释放资源。其他事情不该塞进来。

• 别在 finally 里写业务逻辑、重试、降级或发通知——这些该放在 catch 里
• 避免在 finally 中 return 或 throw，否则会覆盖 try/catch 的返回值或异常
• 临时文件删除建议用 Files.deleteIfExists(path)，比 File.delete() 更健壮，失败时抛明确异常便于排查