需调用 exceptions() 成员函数启用异常模式，如 fin.exceptions(std::ios_base::failbit | std::ios_base::badbit)；eofbit 通常不启用，因文件末尾属正常行为。
如何开启fstream的异常模式
默认情况下，std::fstream（包括 std::ifstream 和 std::ofstream）完全不抛异常，所有错误都只设置内部状态位（failbit、badbit、eofbit），必须手动调用 fail() 或 good() 检查。要让它真正抛异常，必须显式启用——调用 exceptions() 成员函数：
std::ifstream fin("data.txt");
fin.exceptions(std::ios_base::failbit | std::ios_base::badbit);
注意：eofbit 通常不加入异常掩码，因为读到文件末尾是正常行为，不是错误；强行捕获会导致频繁误抛。
哪些操作会真正触发异常
只有在异常掩码中启用的标志被置位时，下一次涉及流状态检查的 I/O 操作才会抛 std::ios_base::failure（继承自 std::system_error）。常见触发点包括：
-
open()失败（如路径不存在、权限不足）→ 置failbit或badbit -
operator>>读取失败（如类型不匹配、空文件读 int）→ 置failbit -
read()或write()底层系统调用失败（如磁盘满、断开的管道）→ 置badbit -
close()失败（如写入缓冲区 flush 出错）→ 置badbit（需在exceptions()中包含它才抛）
注意：operator 向输出流写入时，若只是格式化失败（如对 <code>nullptr 写入 string），一般不设标志，也不会抛异常——它依赖你检查流状态。
try-catch 怎么写才不漏掉错误
异常类型固定为 std::ios_base::failure，但它的 what() 信息往往很简略（如 "basic_ios::clear"），实际调试时需结合原始错误码：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
try {
std::ifstream fin("missing.txt");
fin.exceptions(std::ios_base::failbit | std::ios_base::badbit);
fin.open("missing.txt"); // 这里就抛了
} catch (const std::ios_base::failure& e) {
std::cerr
<p>关键点：</p>
- 必须在
open()之前调用exceptions()，否则构造后首次 open 的错误不会被捕获 - 如果流已处于错误状态（比如之前失败过），再调
exceptions()不会自动重试或清除状态，需先clear() -
std::ios_base::failure的构造可能丢失 errno；需要精确系统错误时，建议用std::system_category().message(errno)辅助诊断
和 C 风格错误处理混用的风险
一旦启用了异常模式，就不要再混合使用 if (!fin) 或 fin.fail() 做主逻辑判断——这不仅冗余，还容易掩盖异常语义。更危险的是：在异常未捕获的上下文中（如析构函数、noexcept 函数），fstream 抛异常会导致程序直接调用 std::terminate。
所以：
- 要么全程用异常（推荐：统一、简洁）
- 要么全程用状态位检查（兼容旧代码、避免 terminate）
- 不要一半 try-catch，一半
if (fin.fail())—— 状态位和异常机制并不同步刷新，行为不可靠
最易忽略的一点：std::fstream 的移动构造/赋值不保证保留异常掩码，转移后新对象需重新调用 exceptions()。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
