std::fstream::exceptions() 默认不抛异常是因为C++流采用状态位驱动错误处理模型，failbit/badbit置位仅改变内部状态而不中断执行；需显式调用并指定状态位组合（如failbit|badbit），且必须在I/O操作前设置，否则已发生的错误不会触发异常。
std::fstream::exceptions() 为什么默认不抛异常
因为 C++ 标准库流的错误处理模型是“状态位驱动”，不是异常驱动。默认情况下，failbit、badbit、eofbit 被设为 true 时，流只是默默改变内部状态，operator>> 或 read() 等操作返回自身（支持链式调用），但不会中断执行。这和 Python 的 open() 或 Rust 的 File::open() 默认 panic / 返回 Result 完全不同。
开启异常需要显式调用 exceptions()，且它只控制“哪些状态位触发异常”，不自动开启所有位。
-
exceptions()接收一个iostate枚举值（通常是按位或组合） - 常见组合：
std::ios_base::failbit | std::ios_base::badbit；eofbit一般不加入，因为读到文件末尾是正常流程，不是错误 - 一旦设置，后续任何导致对应位被置位的操作（如打开失败、读写失败）会立即抛出
std::ios_base::failure
怎么正确设置 exceptions()：顺序和时机很关键
必须在流对象完成初始化（比如构造或 open()）之后、开始 I/O 操作之前调用 exceptions()。如果先调用再 open()，而 open() 失败了，此时 failbit 已被置位但异常还没开，就不会抛出。
- 推荐方式：构造后立刻
open()，检查是否成功，再调用exceptions() - 不推荐方式：构造空流 →
exceptions(...)→open()（此时open()失败不抛异常） - 更安全写法：用
std::ifstream f("path");构造时打开，再判断if (!f) { /* handle open fail */ }，然后f.exceptions(...)
示例：
立即学习“C++免费学习笔记（深入）”；
std::ifstream f("data.txt");
if (!f) {
throw std::runtime_error("cannot open data.txt");
}
f.exceptions(std::ios_base::failbit | std::ios_base::badbit); // ✅ 此时才开启
f >> value; // 若读取失败（比如类型不匹配），抛 std::ios_base::failurestd::ios_base::failure 异常里能拿到什么信息
它继承自 std::system_error，但 what() 返回的字符串通常只含“basic_ios::clear”或类似提示，**不包含具体文件名、行号或 errno**。调试时容易抓瞎。
- 异常对象本身没有存储原始错误码，
code().value()通常是 0（非系统错误） - 真正有用的线索藏在流的状态里：捕获异常后可立即检查
f.rdstate()判断是failbit还是badbit -
badbit通常意味着底层 read/write 系统调用失败（如磁盘满、权限不足），这时可结合errno辅助诊断
所以别指望靠 catch (const std::ios_base::failure& e) 一句就定位问题——得配合流状态和上下文日志。
开启 exceptions() 后的典型错误场景和坑
最常踩的不是“没开异常”，而是开了却没处理好边界情况，导致程序意外终止或逻辑跳过。
- 读取整数但文件里是 "abc"：触发
failbit→ 抛异常（如果你开了failbit） - 写入时磁盘满：触发
badbit→ 抛异常 - 文件被其他进程独占锁定（Windows）：构造
std::ofstream失败 →failbit置位，但若你还没调exceptions()，就不会抛 - 重复调用
exceptions()会覆盖之前设置，不是追加 —— 比如先设failbit，再设badbit，那failbit就失效了
复杂点在于：同一个流对象上，exceptions() 设置是一次性的，且异常行为不可逆（除非你再调一次关掉）。实际项目中，如果某段逻辑需要“容忍部分失败”，最好不用全局开异常，而是用状态位 + if 判断更可控。
