需调用exceptions()设置failbit和badbit掩码，构造后立即设置并显式open()才能自动抛异常；若流已失败则调用exceptions()会立即抛出ios_base::failure。
std::ifstream/ofstream 怎么自动抛异常而不是静默失败
默认情况下，C++ 的 std::ifstream 和 std::ofstream 在打开失败、读到 EOF 或写入出错时，**不会抛异常**，只设置内部状态位（failbit、badbit、eofbit），你需要手动调用 is_open() 或 good() 检查。想让它一出问题就抛 std::ios_base::failure，得主动开启异常掩码。
关键操作就是调用 exceptions() 成员函数——但它不是“开启流异常”的开关，而是**设置哪些状态位触发异常**：
-
std::ios_base::failbit：格式错误、转换失败（如读整数但遇到字母）、open()失败等 -
std::ios_base::badbit：底层 I/O 错误（磁盘满、权限不足、设备断开） -
std::ios_base::eofbit：一般不建议设它，否则每次读到末尾都抛异常，干扰正常逻辑
实操建议：
- 在构造后、任何 I/O 操作前立即调用
exceptions()，比如ifs.exceptions(std::ios_base::failbit | std::ios_base::badbit); - 不要对已关闭或未成功打开的流调用
exceptions()——它会抛异常（因为此时failbit已置位） - 如果用了 RAII 封装（如自定义 FileGuard），记得在构造函数里设好掩码，别漏掉
为什么 try/catch 捕不到 open() 失败的异常
常见错误现象：std::ifstream ifs("missing.txt"); 后直接 ifs.exceptions(...)，结果程序崩溃或捕获不到异常——因为 open() 调用发生在构造函数里，失败时只设 failbit，不抛异常；而你后续调用 exceptions() 时，流已处于失败状态，触发检查即抛 std::ios_base::failure，但此时还没进 try 块。
立即学习“C++免费学习笔记（深入）”；
正确做法是把对象声明和异常设置放在 try 内部，并且**分开两步**：
try {
std::ifstream ifs;
ifs.exceptions(std::ios_base::failbit | std::ios_base::badbit);
ifs.open("missing.txt"); // 这里才会真正抛异常
// ... 使用 ifs
} catch (const std::ios_base::failure& e) {
// 捕获到了
}
或者更简洁地用初始化列表（但注意：构造函数不抛异常，open() 仍需显式调）：
- 不能写
std::ifstream ifs("missing.txt");然后设exceptions()——风险高 - 推荐写法：
std::ifstream ifs; ifs.exceptions(...); ifs.open(...); -
std::ofstream同理，open()或首次写入（如）才可能触发异常
exceptions() 设错掩码导致程序意外终止
容易踩的坑：把 eofbit 加进掩码，比如 ifs.exceptions(std::ios_base::failbit | std::ios_base::eofbit);。后果是：只要一次 read() 或 getline() 遇到文件末尾，立刻抛异常。这不是错误，但会让正常循环读取逻辑崩掉——你本该靠 while (ifs >> x) 或 ifs.good() 判断结束，现在却要每读一次都套 try/catch。
性能与兼容性影响：
- 异常机制本身有开销，但日常文件操作中可忽略；主要成本在错误路径上（本来就要处理失败）
- 所有标准库实现（libstdc++、libc++、MSVC STL）都支持
exceptions()，无兼容性问题 - 注意：某些嵌入式或裁剪版 STL 可能禁用异常（
-fno-exceptions），此时exceptions()调用无效，且编译可能报错
std::fstream::exceptions() 返回值有什么用
这个函数返回旧的异常掩码值，不是 void。用途很实际：临时修改掩码、执行一段操作、再恢复原状。
比如你想让某次 write() 严格失败即抛异常，但其他操作保持静默：
auto old_mask = ofs.exceptions(); // 保存当前设置 ofs.exceptions(std::ios_base::badbit); // 只对底层错误敏感 ofs << data; ofs.exceptions(old_mask); // 恢复
不过多数场景不需要这么精细——全局统一设 failbit | badbit 已覆盖绝大多数问题。真正复杂的是跨线程共享流对象，此时 exceptions() 是非线程安全的，别在多线程里动态改同一对象的掩码。
最常被忽略的一点：exceptions() 只影响**后续操作**，对已经发生的错误状态（比如构造失败后残留的 failbit）无清除作用。必须先 clear() 才能避免立即抛异常。
