IOException 是必须显式处理的检查型异常，不捕获或声明会导致编译失败；而 NullPointerException、SecurityException 等运行时异常可不捕获但建议兜底。
try-catch-finally 里哪些异常必须捕获？
读取文件时，IOException 是必须显式处理的检查型异常（checked exception），不捕获或声明就会编译失败；而 NullPointerException、SecurityException 这类运行时异常（unchecked）可以不捕，但实际中常因路径为空、权限不足等触发，建议一并兜底。
常见错误现象：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() 才能看到。别默认以为“自动关闭=万无一失”。
