析构函数中释放失败绝对不可抛异常，否则会触发std::terminate；应通过close()等显式函数返回错误状态并缓存errno，实现RAII与错误处理解耦。
析构函数里释放失败要不要抛异常
绝对不要。C++标准明确规定：析构函数默认是 noexcept 的，如果在析构中抛出未捕获的异常，程序会直接调用 std::terminate() 终止运行——哪怕你只是想记录一句日志。
常见错误写法：
~FileHandler() {
if (fp && fclose(fp) != 0) {
throw std::runtime_error("fclose failed"); // 危险！
}
}正确做法是：
- 用返回值或成员变量记录失败状态（如
m_close_failed = true） - 在类提供一个显式的
close()成员函数，供调用者主动检查和处理错误 - 析构函数内只做尽力而为的清理（
fclose(fp)），不报告、不重试、不抛异常
RAII类中资源释放可能失败的典型场景
不是所有资源都能“静默释放”。比如：
立即学习“C++免费学习笔记（深入）”；
-
fclose()在缓冲区刷盘失败时返回EOF，但文件句柄已失效 -
pthread_mutex_destroy()对仍被持有的互斥锁调用会返回EBUSY -
close()系统调用对 socket 可能因发送队列未清空而阻塞或失败 -
munmap()一般不会失败，但若传入非法地址会触发 SIGSEGV（此时已不是“释放失败”，而是 UB）
这些情况都说明：RAII 封装不能假设“释放一定成功”，而应把“释放是否完成”和“释放是否干净”拆开看待——前者靠作用域保证，后者需业务层兜底。
如何设计带错误反馈的 RAII 封装
核心原则：把“自动管理生命周期”和“手动处理释放结果”解耦。推荐结构：
- 析构函数只调用底层释放函数（如
fclose），忽略返回值 - 增加
bool close() noexcept成员函数，返回是否成功，并把 errno / 错误码缓存在成员变量中 - 提供
int last_error() const或std::error_code error() const供检查 - 禁止拷贝，允许移动（移动后原对象应置为“已关闭”状态，
close()返回true）
示例关键片段：
class SafeFile {
FILE* fp_ = nullptr;
int last_err_ = 0;
public:
explicit SafeFile(const char* path) : fp_(fopen(path, "r")) {}
~SafeFile() { if (fp_) fclose(fp_); }
bool close() noexcept {
if (!fp_) return true;
int ret = ::fclose(fp_);
fp_ = nullptr;
last_err_ = (ret == 0) ? 0 : errno;
return ret == 0;
}
int error() const { return last_err_; }
};shared_ptr 自定义删除器中释放失败怎么处理
自定义删除器（如 std::shared_ptr<FILE> 配合 [](FILE* f) { fclose(f); }）同样受析构函数不能抛异常的限制。
如果你需要感知释放失败：
- 不要把删除器写成 lambda，改用具名函数对象，内部缓存错误状态
- 让删除器返回
void，但通过外部可访问的变量（如全局原子计数器、线程局部存储）记录失败次数 - 更稳妥的做法：根本不用
shared_ptr管理这类“释放可能失败且需反馈”的资源；改用显式生命周期管理 + RAII 包装类（如上一节的SafeFile）
真正容易被忽略的一点：很多开发者以为“用了 shared_ptr 就万事大吉”，却没意识到——当删除器里调用 fclose 失败时，你既得不到错误通知，也无从重试，资源语义已经残缺。
