如何通过try-catch-finally结构妥善处理文件读取中可能出现的所有异常情况？

本文共计992个文字，预计阅读时间需要4分钟。

读取文件时，IOException 是需要显式处理的检查型异常（checked exception），不捕获或声明就会编译失败；而 NullPointerException、SecurityException 等运行时异常（unchecked exception）可以不捕获，但实际中常因路径为空、权限不足等问题引发，建议妥善处理。

常见错误现象：FileNotFoundException 被吞掉、IOException 仅打印堆栈却不释放资源、finally 块里又抛新异常导致原异常丢失。

• try 块只放真正可能出错的 I/O 操作（如 FileReader 构造、readLine() 调用），别塞无关逻辑
• catch 至少覆盖 FileNotFoundException 和 IOException，顺序不能颠倒（子类在前）
• finally 中关闭资源前务必判空，否则 NullPointerException 会掩盖原始异常

finally 关闭流时为什么还会报 NullPointerException？

因为流对象本身可能是 null —— 比如 new FileReader("missing.txt") 抛出 FileNotFoundException 后，流变量根本没初始化成功。直接调用 close() 就崩了。

实操建议：

• 声明流变量时初始化为 null（如 FileReader reader = null;）
• finally 中先判断非空再关闭：if (reader != null) { try { reader.close(); } catch (IOException e) { /* 记录但不抛 */ } }
• 更稳妥的做法是用 try-with-resources（Java 7+），它自动处理 null 安全和异常抑制，但需确保资源类实现 AutoCloseable

try-with-resources 真的比 try-catch-finally 更安全吗？

是的，前提是正确使用。它把资源声明写在 try 括号里，JVM 保证无论是否异常都会调用 close()，且能正确抑制后续异常（suppressed exceptions），避免原始异常被覆盖。

但要注意这些坑：

• 资源必须是 final 或“有效 final”，不能在 try 块里重新赋值
• 多个资源用分号隔开，关闭顺序与声明顺序相反（后声明的先关）
• 如果 close() 抛异常，它会被添加到主异常的 getSuppressed() 列表里，而不是直接抛出——调试时容易忽略这个细节
• 示例：

  try (FileReader r1 = new FileReader("a.txt"); BufferedReader r2 = new BufferedReader(r1)) { // ... } catch (IOException e) { // e.getSuppressed() 可能包含 r2.close() 的异常 }

catch 块里该记录日志还是重新抛出？

取决于上下文：如果是底层工具方法，建议包装后重新抛出（如 throw new DataLoadException("读取配置失败", e)），让上层决定如何处理；如果是顶层入口（如 main 方法或 Servlet），就该记录完整错误并给出用户友好的提示。

关键原则：

• 不要只写 e.printStackTrace() —— 生产环境日志系统通常抓不到控制台输出
• 记录时带上关键上下文，比如文件路径：log.error("Failed to read file: {}", path, e)
• 不要在 catch 里静默吞掉异常（空 catch 块），除非你明确知道这个异常可忽略（极少见）
• 若需转换异常类型，用构造函数传入原异常（cause 参数），保留堆栈链路

最易被忽略的一点：即使用了 try-with-resources，如果 read() 过程中发生 IO 错误（比如磁盘突然断开），close() 仍可能失败，而这个失败会被抑制——得主动检查 getSuppressed() 才能看到。别默认以为“自动关闭=万无一失”。