17370845950

IOException是受检异常，必须try-catch或throws声明，否则编译失败；Files.readString()等方法将其转为UncheckedIOException，虽免编译检查但运行时仍崩溃，且UTF-8默认解码可能导致GBK中文乱码。

Java中IOException为什么总在编译时报错

因为IOException是受检异常（checked exception），JVM强制要求你显式处理——要么用try-catch捕获，要么在方法签名里用throws声明。不这么做，代码根本编译不过。

常见错误现象：直接调用FileInputStream构造函数或Files.readAllBytes()却不处理异常，IDE立刻报红，提示“Unhandled exception: java.io.IOException”。

• 不是所有IO操作都抛IOException：比如new File("path").exists()不抛，它只返回boolean
• Java 7+ 的Files工具类多数方法（如Files.copy()、Files.delete()）都声明抛IOException，但Files.exists()不抛
• PrintWriter默认吞掉异常（checkError()才暴露），容易误以为“没出错”，实际写入可能已失败

用try-with-resources自动关闭流，但要注意嵌套资源的释放顺序

手动close()容易遗漏或放在catch块外导致未执行；try-with-resources能保证资源在离开作用域时按声明**逆序**关闭（后声明的先关），避免IOException在close()时掩盖主逻辑异常。

典型场景：读文件并解析JSON，需同时管理FileInputStream和InputStreamReader。

立即学习“Java免费学习笔记（深入）”；

try (FileInputStream fis = new FileInputStream("data.json");
     InputStreamReader reader = new InputStreamReader(fis, StandardCharsets.UTF_8)) {
    // 解析逻辑
} catch (IOException e) {
    // 所有close()失败都会合并到这个e里（通过addSuppressed）
}

• 多个资源用分号隔开，它们必须实现AutoCloseable
• 如果第一个资源构造就失败（如文件不存在），第二个不会实例化，自然也不触发关闭
• 不要在try块里对资源变量重新赋值，否则原对象无法被自动关闭

Files类的readString()和writeString()简化了异常处理，但仍有陷阱

Java 11 引入的Files.readString()看起来“不用管异常”，其实只是把IOException包装成UncheckedIOException再抛出——它继承自RuntimeException，编译器不强制处理，但运行时仍会崩。

这意味着：你省了try-catch，但没省掉错误处理责任；线上一旦路径错、权限不足、磁盘满，服务就直接500。

• Files.readString(Path)内部仍可能抛IOException，只是转成了运行时异常
• 它默认用UTF-8解码，若文件是GBK且含中文，会乱码——但不会报异常，只会静默损坏数据
• Files.writeString()默认覆盖写入，没有CREATE_NEW选项，想确保不覆盖得自己加StandardOpenOption.CREATE_NEW

捕获IOException时，别只打日志就完事

很多代码写成catch (IOException e) { logger.error("", e); }，看似处理了，实则丢失关键上下文：哪个文件？什么操作？权限还是路径问题？

更务实的做法是记录可定位的信息，并根据场景决定是否重试或降级。

• 在catch块里补全操作描述："Failed to read config file: " + path.toString()
• 区分具体子类：比如FileNotFoundException可提示用户检查路径，AccessDeniedException（继承自IOException）说明权限问题，应查OS级设置
• 网络文件系统（NFS/SMB）上IO异常常瞬时发生，对read/write操作可考虑简单重试（最多1–2次），但delete不能盲目重试

复杂点往往不在语法——而在于你是否清楚每个IOException背后对应的真实系统状态。