fstream::exceptions()默认不抛异常，需手动设置failbit和badbit位以启用异常；eofbit通常不启用，因读取到文件末尾属正常行为；异常应在流创建后、首次I/O前调用，否则可能遗漏初始化错误。
fstream::exceptions() 默认不抛异常，必须手动开启
默认情况下，fstream 所有操作失败（比如打开不存在的文件、读到 EOF、磁盘满）都只是设置内部状态位（failbit、badbit、eofbit），不会抛异常。想让它出错就炸，得主动调用 exceptions() 设置触发条件。
常见错误现象：ifstream f("missing.txt"); f >> x; 即使文件根本不存在，也不会报错，后续 f.fail() 才返回 true——很多人误以为“没报错=成功”，结果用着空数据往下跑。
-
exceptions()必须在流对象创建后、首次 I/O 操作前调用，否则可能漏掉初始化阶段的错误（比如构造时文件路径非法） - 推荐写法：
std::ifstream f("data.txt"); f.exceptions(std::ios_base::failbit | std::ios_base::badbit); - 一般不加
eofbit：读到末尾是正常流程，不是错误；加了会导致>>或getline()在 EOF 时意外抛std::ios_base::failure
failbit 和 badbit 的区别直接影响哪些操作会抛异常
failbit 表示逻辑失败（如格式不匹配、提取不到预期类型），badbit 表示底层流损坏（如写入只读文件、磁盘 I/O 错误）。两者常一起开，但理解差异能帮你精准定位问题。
使用场景举例：
立即学习“C++免费学习笔记（深入）”；
-
failbit触发：用int x; f >> x;读到字母 "abc" → 抛异常 -
badbit触发：用ofstream f("/root/protected.txt"); f （权限不足）→ 抛异常 - 只开
failbit时，badbit出现不会抛异常，但流状态已坏，后续所有操作都失效（除非 clear()）
异常类型固定为 std::ios_base::failure，捕获时注意构造细节
无论什么错误，fstream 抛的都是 std::ios_base::failure，它继承自 std::system_error，但**不是所有实现都带有效 code()**。别指望靠 error_code 区分是 open 失败还是 read 失败。
实操建议：
- 捕获时直接用
catch (const std::ios_base::failure& e)，别试图 downcast - 错误信息来自
e.what()，但内容依赖标准库实现：libstdc++ 通常包含操作名（如 "basic_ifstream::open"），libc++ 可能只返回空字符串或简单提示 - 若需区分错误类型，得结合流状态位判断：
if (f.fail()) { /* 格式/逻辑错 */ } else if (f.bad()) { /* 底层错 */ }，但这要在 catch 块里做（先f.clear()再查）
和 C 风格错误检查混用容易导致状态混乱
一旦开了 exceptions()，就别再频繁手动调用 good()、fail() 等——异常抛出后流状态未定义，部分实现会清空状态位，部分则保留，行为不一致。
典型坑：
- 写了
f.exceptions(failbit); try { f >> x; } catch(...) { if (f.fail()) {...} }→f.fail()可能返回 false，因为异常抛出后状态已被重置 - 更糟的是在异常 handler 里继续用该流对象读写：未 clear() 就操作，行为未定义
- 正确做法：异常捕获后，明确调用
f.clear()再检查状态，或直接重建流对象
复杂点在于：异常机制和状态位机制共存时，谁主导控制流取决于你是否及时响应异常。漏 catch 一次，后面所有状态检查都可能失真。
