c++oding="utf-8" ?>
默认情况下std::ifstream/open不抛ios_base::failure，需显式调用exceptions()启用failbit/badbit掩码；掩码必须在i/o操作前设置，否则静默失败。
为什么 ios_base::failure 捕获不到文件打开失败？
直接结论：默认情况下，std::ifstream 或 std::ofstream 的构造函数和 open() 不会抛出 ios_base::failure，除非你显式开启异常掩码。C++ 流的异常是“按需启用”的，不是默认打开的。
常见错误现象是写了 try-catch 却完全没进 catch，文件路径错、权限不足、磁盘满等都静默失败——因为流对象只是把 failbit 置位，不抛异常。
-
std::ios::exceptions()必须被调用，且传入要监控的标志（如std::ios_base::failbit | std::ios_base::badbit） -
failbit覆盖打开失败、读取格式错误、>>提取失败等；badbit对应底层 I/O 错误（如磁盘故障、写入只读文件） -
eofbit一般不加入异常掩码，否则每次正常读到末尾也会抛异常
如何正确启用并捕获 ios_base::failure？
启用必须在流对象创建后、任何 I/O 操作前完成。顺序错了就等于没开。
std::ifstream fin("missing.txt");
fin.exceptions(std::ios_base::failbit | std::ios_base::badbit); // ✅ 正确：设掩码
try {
fin >> some_value; // 若文件打不开或读取失败，这里抛 ios_base::failure
} catch (const std::ios_base::failure& e) {
std::cerr
- 对
std::ofstream同理，但注意：仅写入失败（如磁盘满）触发badbit；若路径无效但目录可写，open()可能成功（创建空文件），后续才失败 -
e.what()返回的字符串通常包含 C 标准库strerror()的内容，但不保证跨平台一致；需要精确错误码时，得从e.code().value()提取（C++11 起） - 不要对同一个流多次调用
exceptions()而不保存原掩码——它会覆盖，可能意外关闭已有异常项
ios_base::failure 和系统错误码怎么对应？
ios_base::failure 是异常类型，其内部封装的 std::error_code 才反映真实系统错误。直接打印 e.what() 只是辅助信息，不可用于逻辑分支判断。
- 检查具体错误：用
e.code().value()获取 errno 值（Linux/macOS）或 Windows 错误码 - 区分场景：
e.code().value() == ENOENT表示文件不存在；== EACCES表示权限拒绝；== ENOSPC表示磁盘空间不足 - 注意：某些实现（如旧版 libstdc++）可能未完整填充
error_code，建议配合流状态检查（fin.fail()/fin.bad()）做兜底
比 try-catch 更轻量的错误检查方式是否更合适？
对多数简单场景（比如“读配置文件，不存在就用默认值”），直接检查流状态比铺开 try-catch 更自然、无异常开销，也避免掩盖真正该 panic 的错误。
std::ifstream fin("config.txt");
if (!fin.is_open()) {
std::cerr > port)) {
std::cerr
-
try-catch适合“错误是异常路径，且需统一处理”的情况（如日志服务批量写入，任一失败需回滚） - 混合使用常见：先用状态检查快速失败，关键操作（如事务性写入）再套异常捕获
- 别忘了：异常一旦抛出，流对象仍处于失败状态，下次操作前需调用
clear()（但通常你该重建流对象）
真正容易被忽略的是掩码设置时机和 error_code 的可靠性——很多代码把 e.what() 当作结构化错误来解析，结果在不同编译器或标准库版本上行为不一致。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
