std::fstream::exceptions()默认不抛异常是因为C++ I/O流设计采用“失败静默+状态位检查”哲学，避免隐式异常中断流式操作链；需手动调用并传入failbit|badbit等掩码开启，且须在open()后调用。
std::fstream::exceptions() 为什么默认不抛异常
因为 C++ 标准库的 I/O 流设计哲学是“失败静默 + 状态位检查”，std::fstream 默认关闭异常，靠 fail()、bad()、eof() 手动查错。这不是 bug，是刻意为之——避免隐式异常打断流式操作链（比如 ifs >> x >> y >> z 中间出错就炸）。
但如果你明确想用异常兜底（比如写配置加载器、测试断言、或讨厌状态位轮询），就得手动开。
-
exceptions()只影响后续操作，不影响已打开的流状态 - 必须在
open()或构造之后调用，构造时传 flag 不生效 - 它设置的是“触发异常的错误类型掩码”，不是开关按钮
怎么正确开启 read/write/fail/bad 的异常
调用 exceptions() 时传入位或组合的 iostate 值，常见组合：
-
ifs.exceptions(std::ios_base::failbit | std::ios_base::badbit);—— 最常用：文件打不开、格式解析失败、磁盘满都抛异常 -
ofs.exceptions(std::ios_base::failbit | std::ios_base::badbit);—— 输出流同理 - 别加
eofbit：读到结尾是正常流程，加了会导致while (ifs >> x)每次 EOF 都抛异常 - 别在
try外调用：如果open()已失败，再调exceptions()也没用；先确保流处于可用状态
示例：
立即学习“C++免费学习笔记（深入）”；
std::ifstream ifs("config.txt");
ifs.exceptions(std::ios_base::failbit | std::ios_base::badbit);
// 后续任何 read/fail/bad 都会 throw std::ios_base::failure
捕获什么异常？和 errno 有关系吗
只抛一种异常：std::ios_base::failure，它是 std::system_error 的派生类（C++11 起），但**不携带 errno**。它的 what() 通常只含简单描述（如 "basic_ios::clear"），不带系统级错误码。
- 想拿具体错误码？得自己调
std::errno（仅限badbit常关联底层 syscall 失败） -
failbit抛异常时，errno往往是 0（比如数字解析失败，根本没进 syscall） - 别 catch
std::exception&就完事——要精确捕获std::ios_base::failure，否则可能吞掉其他无关异常
容易被忽略的坑：缓冲区、移动语义和 RAII
开了异常不等于安全。几个硬伤点：
- 流对象被移动后（如传入 lambda 或容器），原对象的
exceptions()设置丢失，新对象恢复默认无异常 -
std::getline()、operator>>等函数内部可能先改流状态再抛异常，导致rdstate()在 catch 块里不可靠 - 析构时若流未关闭且
badbit已置位，不会自动抛异常（析构函数不抛异常是铁律），资源泄漏风险仍在 - 多线程下不要共享一个流对象并动态改
exceptions()—— 状态位和异常掩码都是对象级，非线程局部
真正稳的做法：每个流初始化即设好 exceptions()，全程不改；配合 RAII（如封装成 SafeInputFile 类），不在裸指针或临时对象上折腾。
