AI传送门1. 析构函数里抛异常，为什么会让整个进程直接“自杀”
我第一次被析构函数里的异常坑到，是在一个数据采集服务上。那个服务跑了两三天后突然进程消失，日志里没有留下任何业务层面的报错，只有一行类似“terminate called after throwing an instance of ...”，以及一个残缺的 core 文件。排查到最后，问题出在一个数据库连接对象上：它的析构函数在关闭连接时会尝试重连，重连失败就抛异常，而这个异常直接逃出了析构函数，触发了 std::terminate，整个进程当场终止。
这就是《Effective C++》条款8想讲的核心问题。条款原文很短，意思也很明确：析构函数绝对不要吐出异常。如果真的在析构函数里发生了可能失败的清理操作，比如释放资源、关闭连接、写日志、flush 缓冲区，你要么自己吞掉异常，要么设计成让用户有机会显式调用一个完成操作的函数，把错误处理的责任从“自动析构”转移到“显式调用”。
这个条款在 2005 年出版的时候就很重要，到了 C++11 之后，它的重要性不降反升。原因很简单：C++11 开始，析构函数默认是 noexcept(true)。也就是说，就算你的析构函数里写了 throw，编译器也会默认它不会抛异常，一旦运行到真的抛出异常时，程序直接调用 std::terminate，连“尝试一下栈展开”的机会都不给你。后面我会专门讲这个变化，先把这个结论刻在脑子里：析构函数里一但往外抛异常，进程死亡概率非常高，而且死得极其难看。
1.1 从“析构”到“崩溃”只需要一个 throw
先看一个最直接的场景。你写了一个类，里面持有某个数据库连接，连接需要显式关闭：
cpp复制class DBConnection {
public:
static DBConnection create();
void close(); // 可能抛异常
};
class DBConn {
public:
~DBConn() {
db.close(); // 如果 close 抛异常，会怎样？
}
private:
DBConnection db;
};
DBConn 的析构函数里调用了 db.close()，而 close() 是有可能抛异常的。如果这个异常没有被捕获，它就逃离了析构函数。看起来好像“也没多大事，最多报个错”？完全不是。
关键点在于：当异常离开析构函数时，C++ 运行时会认为这个异常没有被正确处理。如果析构函数是在栈展开的过程中被调用的（就是说：某个作用域里已经有了一个异常在传播，异常处理机制正在销毁沿途的栈对象，销毁到你的 DBConn 时，析构函数又抛了一个新异常），那么系统同时面对两个异常，根本无法决定该用哪个去匹配 handler，于是直接调用 std::terminate，进程终结。
即使不是在栈展开过程中——比如正常情况下作用域结束，对象析构——抛出异常一般也会导致 std::terminate。标准规定，析构函数默认就是 noexcept(true) 的，异常一旦跨越析构函数的边界，那就是违反了 noexcept 约定，直接触发 terminate。结论极其干脆：析构函数里的异常，就是一颗定时炸弹，而且引爆路径极短。
你可以自己做个实验，这段代码基本上会把它放在的大部分环境跑崩溃：
cpp复制#include <iostream>
#include <stdexcept>
struct Foo {
~Foo() {
throw std::runtime_error("oops");
}
};
int main() {
try {
Foo f;
throw std::runtime_error("something else");
} catch (const std::exception& e) {
std::cout << "caught: " << e.what() << std::endl;
}
return 0;
}
我把这段代码发给不同经验水平的人看过，很多新手会以为外层 catch 能拦住这个异常，毕竟 try 块里确实有两个异常源。但结果是：这个程序大概率直接调用 terminate，连 caught: 都打印不出来。因为当 throw std::runtime_error("something else") 触发栈展开时，Foo 的析构函数又抛了 oops，两个异常同时存在，运行时只能选择 terminate。
如果是普通的函数，你可以在一个 try-catch 里调用它，然后“优雅地处理”错误。但析构函数没有这个待遇，尤其当它出现在栈展开路径上的时候，C++ 运行时宁可杀掉进程也不愿意猜。
1.2 二重异常爆炸：栈展开期间的追加异常
上面已经提到“两个异常同时存在”这个场景，我再把它拆细一点，因为这是最容易让人轻视的地方。
所谓栈展开，指的是异常从抛出点开始，沿着调用栈向上寻找 handler 的过程。在这个过程中，所有已经构造完成的局部对象都会被析构，释放栈帧资源。这是一个递归的过程：从抛异常的帧开始，逐层向外走，每层都销毁该层定义的对象。
现在的问题就来了：如果第一个异常已经“走到一半”，正在析构某层局部对象，而局部对象的析构函数突然抛出第二个异常，C++ 标准认为这是一个不可恢复的局面，因为两个异常同时存在时，如果选择让第二个异常继续传播，那第一个异常就丢了；如果让第一个异常继续传播，第二个异常又没法处理。无论哪一种，都会导致部分资源的清理逻辑被打断，程序状态不可信。所以标准干脆规定：此时直接调用 std::terminate。
这不是理论上的罕见情况。凡是写过网络服务的人都会在实际代码里遇到：请求处理函数里抛了业务异常，函数栈上的某个连接管理对象在析构时去关闭 socket，关闭失败又抛了一个网络层异常。瞬间进程消失，日志里面全是 what(): ...。最常见的后果就是线上服务突然没了，运维一脸懵，你查半天也查不到业务逻辑的错误，最后才发现是析构函数里的“小小 throw”闯的祸。
这条线的逻辑要彻底理清楚：析构函数本身不害怕发生错误，它害怕的是把错误用异常的形式传播出去。 这就引出了条款8给出的两个经典解决方案。
2. 条款8的核心解法：吞掉还是转移？两种方案各有适用边界
Scott Meyers 在条款8里给了两条路：要么在析构函数里捕获异常并吞掉它，要么提供一个普通成员函数（比如 close()）让用户主动调用，析构函数只作为兜底。
很多人在看这个条款时会觉得“这不是废话吗？在析构函数里 try-catch 一下不就行了？”但实际工程里，选哪条路要结合实际资源类型和错误处理策略，并不是所有场景都适合无脑吞异常。下面详细拆一拆。
2.1 方案A：析构函数里捕获所有异常，吞掉或记录
回到上面的 DBConn 类，最直接的做法是：
cpp复制class DBConn {
public:
~DBConn() {
try {
db.close();
} catch (const std::exception& e) {
// 记录日志，绝不让异常逃出析构函数
std::cerr << "close failed: " << e.what() << std::endl;
} catch (...) {
std::cerr << "close failed: unknown exception" << std::endl;
}
}
private:
DBConnection db;
};
这段代码的思路是：析构函数是资源清理的最后一道关口，它的任务是“必须把资源释放干净”，至于释放过程中是否出错、出错后怎么处理，那是另一层逻辑。析构函数能做的就是尽量不阻塞清理流程。
这种方案的优点非常明显：简单、靠谱、直接避免 terminate，无论顶层业务是否已经在处理异常，析构函数都不会插一脚。它的适用场景也很广——那些“清理失败对业务流程没有致命影响”的资源类型，比如关闭临时文件、释放锁、关闭一个不太重要的网络连接，都可以这么做。
但吞掉异常不代表“错误消失了”。如果 close() 失败意味着数据没写完整，或者资源状态残留，单纯吞掉异常会让调用方完全察觉不到问题。所以吞掉异常的同时，至少要记录足够的信息，否则这就是掩盖错误而不是处理错误。我曾经在项目里看到过析构函数里 catch (...) 然后啥都不干的代码，后来上线后发现某个模块的临时文件一直删不掉，排查了很久没头绪，最后才发现是析构函数吞掉了删除失败的错误，导致问题被静默隐藏。所以我的建议是：可以吞异常，但吞之前必须写日志或做记录，哪怕是打一行日志都行。
2.2 方案B：提供 close() 接口，把异常处理责任交还给用户
条款8还提出了第二种方案，我认为这是工程上更优雅的一种：
cpp复制class DBConn {
public:
void close() { // 新加的成员函数，而不是析构函数
try {
db.close();
closed = true;
} catch (...) {
std::cerr << "close failed" << std::endl;
closed = false;
}
}
~DBConn() {
if (!closed) {
try {
db.close();
} catch (...) {
// 兜底：即便关闭失败也不能抛异常，记录一下
}
}
}
private:
DBConnection db;
bool closed = false;
};
核心思路是：给用户一个显式的 close() 函数，让业务代码在合适的时机调用，并且可以对关闭过程的失败做出反应。析构函数里只做一个“兜底”动作——如果用户忘了调用 close()，析构时才会去尝试关闭。此时如果关闭失败，也只能记录下来，不能抛异常。
这样做的价值在于：错误处理的时机从“无法干预的析构时刻”转移到了“业务可控的调用时刻”。 用户可以在一个完整的 try-catch 块里调用 close()，得到异常后决定是重试、回滚、还是丢弃相关数据。而析构函数只负责两件事：检查用户是否已经完成必要的收尾，没有就代为收尾，但收尾失败也不影响对象销毁。
这种设计在资源管理类里非常常见。想一想标准库里的 std::fstream，它的 close() 就是显式调用的，而析构函数也会尝试关闭文件。如果你在 close() 时没有检查状态，那么析构时发生的写入错误可能就被悄悄吞掉了。很多初学文件流的人会踩这个坑：明明写了文件，却没调用 close() 或没有检查流状态，结果数据不完整还找不到原因。
方案B的适用场景是：资源清理失败可能对业务有实际影响，且用户需要知道清理结果。比如数据库事务提交、文件刷新到磁盘、网络连接的对端确认关闭。这类场景下，如果“关闭失败”对用户是不可见事件，后续数据一致性和可靠性都会受影响。所以这类资源的关闭动作应该设计成普通成员函数，析构函数只兜底。
2.3 两种方案怎么选：给一个简洁的决策标准
很多人搞不清什么时候该用方案A，什么时候该用方案B。我的决策标准非常简单：
- 如果资源清理失败，不影响业务结果、不危害资源状态，或者说失败了也无法重试、无法补救，那就在析构函数里吞掉并记日志。典型如：释放互斥锁、关闭只读文件、释放已经无用的临时对象。
- 如果资源清理失败，需要业务层感知并决策，比如写缓存失败、数据库事务提交失败、网络连接发送剩余数据失败，那就一定要提供一个普通函数，让业务代码在正常执行路径上调用并处理异常。析构函数只能做兜底，兜底时也只记录不抛出。
一句话总结：析构函数是“最后防线”，不是“正常错误处理通道”。 任何需要用户感知的错误，都应该在设计上给出比“析构”更早、更可控的处理机会。
3. 我在真实项目里踩过的析构函数异常连锁坑
理论讲多了容易让人觉得“只要我在析构函数里包个 try-catch 就万事大吉”。但实际工程里，析构函数异常往往不是单独出现的，它会和其他机制纠缠在一起，变成一个特别难排查的疑难问题。下面分享几个我踩过的典型坑，每个都有完整的前因后果，希望能帮你提前避开。
3.1 坑一：析构函数里 flush 日志缓冲区，flush 失败导致写日志的服务崩溃
这是一个非常典型的场景：项目里封装了一个 Logger，析构函数里会把缓冲区里的文档写入文件，并且调用了 ofstream::flush()。flush() 本身一般不抛异常，但如果磁盘满了、文件权限变更、磁盘 IO 错误，底层会设置流的 badbit，并且在开着异常掩码时会抛 ios_base::failure。
当时项目的日志模块在析构时开启了流异常，原本是想“写入失败立刻发现问题”，结果导致程序退出阶段崩溃。最让人头疼的是，崩溃发生在 main 函数返回之后——全局静态对象 Logger 析构的时候。你很难用 gdb 断点去追踪，因为进程已经处于收尾阶段，周围对象都在被销毁，随便一个二次异常都会直接 terminate。
排查出的根因很简单：全局对象的析构顺序完全不受你控制，某个全局对象在析构时调用了 Logger 写日志，而 Logger 自己的析构函数又因为磁盘问题抛出了异常。两个异常叠加，进程直接崩。解决方案也很实在：日志模块的析构函数里所有可能产生 IO 的操作全部套上 try-catch，且不再通过异常暴露错误。因为日志功能本身就要求“绝不能因为打日志而把业务服务搞挂”，这个原则在工程里必须被严格执行。
3.2 坑二：容器析构时，多个元素的析构函数同时抛出异常
另一个容易踩坑的地方是容器。比如一个 std::vector<std::shared_ptr<T>>，当 vector 析构时，会依次析构每个元素。如果每个元素的析构函数都尝试关闭自己的连接，而这些连接全部失败了，它们各自抛异常——这时候会发生什么？
先说结论：行为等同于“第一个异常导致 terminate”。因为 vector 析构时一旦有元素析构抛出异常，异常会立即向外传播，而 vector 的析构函数本身有 noexcept 保证，于是直接 terminate。更糟糕的是，剩余那些还没析构的元素可能处于“部分析构”状态，资源泄漏被永远定格在那一刻。
这个场景我是在一个音频采集模块里遇到的。Sink 对象的析构函数会关闭硬件设备，而设备在异常断电后返回了错误状态码，析构函数在解析错误时抛了个异常。结果整个采集进程在退出时崩溃，之前实时写入的音频文件全部处于未正常结束的状态。后来把 Sink 的析构改成“只尝试关闭、失败仅记录”，问题才彻底解决。
处理这种容器场景的核心经验是：如果你的代码里存在“容器元素在析构时可能做失败性操作”，请务必保证这些操作的析构函数是 noexcept 的。要么你在析构函数内部把异常拦下，要么你在元素销毁前显式调用清理函数。不要依赖容器析构顺序来替你兜底，容器它不负责处理元素析构异常。
3.3 坑三：与 C++11 之后默认 noexcept 的摩擦
这是我看到很多老代码升级到 C++11/14 后突然出现崩溃的原因之一。老的编译器、老的 C++ 标准并没有明确要求析构函数默认是 noexcept(true)，所以老代码里析构函数抛异常还能撑一段时间，最坏也只是调用 std::unexpected 或动态异常规格处理。但 C++11 之后，默认规则变了：析构函数默认 noexcept(true)。
这意味着你写的这一行：
cpp复制struct Foo {
~Foo() {
throw 1;
}
};
在 C++11 之后，即使你什么都不做，编译器也会认为析构函数不会抛异常。当 throw 1 真的执行时，标准库直接调用 std::terminate。这不是“可能崩溃”，而是“必然崩溃”。我见过一整个团队在升级编译器后突然频繁遭遇 exit code 134（SIGABRT），排查很久才发现是一些第三方库的析构函数里抛出了异常，它们在旧编译器下没有触发 terminate，新编译器下一触即发。
如果你在维护 C++11 以上的老项目，建议动手做一次全局搜索：查看所有析构函数里是否直接或间接调用了可能抛异常的函数（比如 close()、exit() 之外的系统调用、第三方的网络接口、可能抛出 std::system_error 的线程操作等）。凡是有可能抛出的，要么用 try-catch 包住，要么给析构函数显式加上 noexcept(false)（但尽量别这么做，除非你有充分理由让上层处理异常并通过特殊机制调查，比如测试框架）。基本上，生产代码的析构函数都应该保持 noexcept 或默认状态，内部自行消化所有错误。
4. 现代C++中条款8的延伸：noexcept、exception_ptr 与移动语义
条款8写于 C++03 时代，但它的精神在现代 C++ 里不仅没过时，反而越来越重要。这一节想讨论几个与析构函数异常强相关的现代语法点，它们能让你的代码既安全又灵活。
4.1 C++11 起析构函数默认 noexcept（true）：一个“强制”约定
前文已经多次提到这个默认规则。需要补充的是，标准允许你显式声明析构函数为 noexcept(false)，这等于明确告诉编译器：我的析构函数可能抛异常，请允许异常向外传播。
但这里有个极易被误解的点：声明 noexcept(false) 并不会阻止 terminate。 如果你在析构函数里抛了异常，而这个异常恰好发生在栈展开期间，照样调用 terminate。noexcept(false) 只影响“正常析构”场景下的传播行为，无法解决二重异常爆炸问题。所以我的态度是：除非你是写测试框架或特殊基础组件，否则 noexcept(false) 的析构函数在生产代码里几乎不该出现。它就是第三方的坑、老代码升级的坑，而不是你要主动使用的武器。
如果你真的需要一个“析构时可能失败”的组件，应该把这个组件设计成普通类，并让用户在正常生命周期内调用显式 finalize() / close() / commit() 方法，而不是把失败留给析构函数。
4.2 用 std::exception_ptr 暂存“析构期间发生的异常”
有时候我们希望既不在析构函数里抛异常，又能让调用方稍后意识到清理时发生了错误。C++11 提供了 std::exception_ptr，可以把异常捕获后保存下来，之后再重新抛出或检查。
比较经典的一种模式是：析构函数里捕获异常，存储到某个可查询的状态对象中；稍后业务代码可以查询这个状态并决定如何处理。
cpp复制class ResourceOwner {
public:
void close() {
try {
resource_.close();
closed_ = true;
} catch (...) {
last_error_ = std::current_exception();
throw; // 如果是显式 close，允许抛出
}
}
~ResourceOwner() noexcept {
if (!closed_) {
try {
resource_.close();
closed_ = true;
} catch (...) {
last_error_ = std::current_exception();
// 不抛出，留给使用者通过 check_error() 查询
}
}
}
void check_error() const {
if (last_error_) {
std::rethrow_exception(last_error_);
}
}
private:
Resource resource_;
bool closed_ = false;
std::exception_ptr last_error_;
};
这个设计的好处是：显式 close() 时，异常会被原样抛出，调用方可以感知；如果用户忘了调用 close()，析构函数会兜底关闭并把异常暂存在 exception_ptr 中，之后用户可以通过 check_error() 检查。当然，这种模式只适合“对象还被某个作用域引用，且用户能检查它的状态”的场景。如果对象是一个全局实例，析构发生在 main() 之后，那 check_error() 大概率没有调用者，也只能靠日志来保留现场。
4.3 移动语义下的析构函数异常：空指针并不总能救你
移动语义出现后，很多资源管理类喜欢把“已移动的对象”置为空，让它的析构函数变成一种“空操作”。比如 std::unique_ptr 被移动后，原指针置空，析构函数只删除空指针，不会真正调用 delete。但这个模式建立在“被移动对象不再持有资源”的假设上，如果你自己写的资源管理类在移动后忘了把原对象的状态置空，那么析构函数仍然会尝试释放资源，仍然可能抛异常。
这里特别要提醒的是：自定义析构+自定义移动构造时必须把源对象的资源句柄清零，否则源对象析构时会重复释放资源。虽然这可能不是异常类的直接问题，但它会引发“在析构函数里释放已失效资源”的路径，而这条路径上经常出现系统错误码、网络异常等。
另外，标准库要求移动构造函数和移动赋值运算符通常应为 noexcept，因为它们可能在容器操作（比如 vector 扩容）中被调度。如果你在移动构造里做了可能抛异常的资源转移，容器回退时会很痛苦，而且会导致元素被拷贝而非移动，性能下降。这里和析构函数异常的关系是：把资源转移想清楚，析构函数才能简单可靠。
5. 异常安全级别与架构设计：别把整个体系建立在“析构函数不出错”上
条款8表面上是关于“不要在析构函数里吐异常”的一个禁令，但它背后其实牵扯到整个程序的异常安全策略。如果你只在析构函数上打补丁，而不从架构层面考虑资源清理流程，你迟早会在其他环节遇到类似的痛苦。
5.1 基本保证、强保证与不抛保证：析构函数要落在哪一种？
异常安全等级通常分为三档：
- 基本保证：抛出异常后，对象处于合法但不确定的状态，资源不泄漏，可以继续销毁。
- 强保证：抛出异常后，对象状态完全回滚到调用之前，仿佛没有发生操作。
- 不抛保证：函数绝不抛出异常，总是成功或直接终止。
析构函数最合理的目标是“不抛保证”（noexcept）。因为析构函数一旦抛出，基本保证已经很难兑现：对象正在被销毁，你无法回到“调用之前”的状态，也没有办法保证所有资源都正确释放。唯一能让析构函数保持不抛的手段就是在函数内部处理所有错误，不让错误以异常形式外泄。
如果你的类里有些操作需要强保证，那应该是普通成员函数的职责，比如 commit()、close() 之类。析构函数只做“尽力而为”的清理，而不承担复杂的业务保证。这句话翻译成人话就是：别把复杂的“成功/失败决策”放到析构函数里，析构函数只管释放，不负责判断业务对错。
5.2 把“析构时处理”提前到“调用时处理”的架构习惯
我在阅读大量他人代码后发现一个规律：风险比较高的清理动作，如果都拖到析构函数才做，架构上往往是懒散设计的。因为析构函数会自动调用，所以写代码的人就省去了在每条退出路径上显式调用清理函数的麻烦。但这种“方便”会付出代价——错误无法被正常传播，调试难度直线上升。
更好的习惯是：把资源所有权和资源清理的时机明确化。比如使用 RAII 管理锁、文件句柄、内存，这类资源的清理比较“机械”，不太需要业务层感知，可以放心交给析构函数。而对于“有业务语义的收尾动作”，比如提交事务、发送 Keepalive 关闭消息、把缓冲区的最后一块数据刷到磁盘，尽量提供显式方法，让业务代码通过 finally 或 RAII 包装类来调用，而不是依赖普通对象的析构函数。
实践中一个不错的折中方案是：编写一个小的 RAII 包装器，比如 TransactionGuard，它的析构函数不会抛异常，但它的 commit() 方法可以被显式调用并在异常时回滚；如果析构函数执行时发现尚未 commit，则会自动回滚。这样既给了用户显式 commit 的机会，又保证析构时不会因为 commit 失败而抛异常。
5.3 我个人总结的几条实操经验
最后分享几条实操经验，是我踩过坑、复盘后沉淀下来的：
第一，代码审查时看到析构函数里有非平凡调用，先亮黄牌。 如果析构函数调用了网络操作、文件操作、加锁/解锁之外的复杂逻辑，一定要确认异常是否被完全捕获。尤其是直接调用第三方库的 close() 或 release() 时，务必要查清这些函数是否会抛出异常。
第二，析构函数里捕获异常后，记得处理“错误码或日志”而不只是吞掉。 最差的做法是 catch (...) {} 然后什么都不做。这会让所有问题彻底隐身。即便在析构函数里，也应该把错误信息记录到日志或传递给一个全局的错误收集器。你至少要知道你的资源清理在什么时候失败了。
第三，如果某个资源清理真的可能会失败，而且失败会带来严重后果（比如数据损坏），那就不要让这种清理任务发生在析构函数里。 一定要设计出一个显式接口，让用户在最合适的时机调用，析构函数只作为兜底。换句话说，条款8的“方案B”不是可选项，而是这类场景下的必选项。
第四，养成检查编译器警告的习惯。 现代编译器（GCC、Clang、MSVC）会在析构函数里检测到异常抛出时给出警告，甚至 -Wterminate、-Wexceptions 这类选项能直接定位到具体行。如果你的项目启用了 “warnings as errors”，这些问题会在编译阶段暴露，而不是等到线上崩溃。我建议所有 C++ 项目中至少开启：
bash复制-Wall -Wextra -Wpedantic
对于析构函数相关检查，GCC 和 Clang 还可以开启：
bash复制-Wterminate -Wexceptions
把潜在问题扼杀在编译期，要比事后分析 core 文件快一个数量级。
6. 进阶话题：自定义 deleter、shared_ptr 与异常交互的坑
除了直接定义析构函数，智能指针的自定义 deleter 也是析构函数异常的“易感区”。
6.1 shared_ptr 自定义 deleter 抛异常，同样直接 terminate
我遇到不止一次类似于下面的代码：
cpp复制auto conn = std::shared_ptr<DBConnection>(
new DBConnection(...),
[](DBConnection* c) {
c->close(); // 如果 close 抛异常？
delete c;
}
);
lambda 在这里扮演了 deleter 的角色，它会在 shared_ptr 引用计数降为零时被调用。如果 close() 抛异常，这个异常会从 deleter 里逃出来，而 shared_ptr 的析构逻辑是 noexcept 的，所以照样触发 terminate。这和类析构函数抛异常本质一模一样，只是发生的位置从“你的析构函数”变成了“deleter”。
结论是：自定义 deleter 内部必须捕获所有异常。 如果确实需要知道关闭失败，可以用 exception_ptr 暂存，或通过回调上报。
6.2 unique_ptr 与文件句柄等资源的析构删除
std::unique_ptr<T, D> 的默认 deleter 调用 delete，一般不抛异常。但如果你给 unique_ptr 传入自定义 deleter，例如：
cpp复制auto file_deleter = [](std::FILE* f) {
std::fclose(f); // 不抛 C++ 异常，但可能失败并设置 errno
};
std::unique_ptr<std::FILE, decltype(file_deleter)> file_ptr(std::fopen("a.txt", "w"), file_deleter);
这类代码相对安全，因为 C 库函数不会抛 C++ 异常。但要防止的是“deleter 里调用了用户自定义的复杂函数”，比如 closeDB()、sendFarewell()、disconnect()。这些函数完全可能有异常路径。所以安全原则与上面的析构函数完全一致：自定义 deleter 里如果必须调用可能抛异常的代码，先在 deleter 内部捕获。
6.3 一个相对安全的自定义 deleter 模板
如果你做的事情较细，可以写一个通用的安全 deleter 辅助函数：
cpp复制template <typename Func>
auto make_noexcept_deleter(Func&& f) {
return [func = std::forward<Func>(f)](auto* p) noexcept {
try {
func(p);
} catch (...) {
// log...
}
delete p;
};
}
这个模板可以把任何可能抛异常的自定义清理逻辑包装成 noexcept deleter，但注意 delete p 只在你确实希望自己管理内存时使用。使用前必须想清楚所有权。如果你用它包了一个第三方连接对象，而这个对象真正释放方式是调用 release() 而不是 delete，那就不能硬套。总之，核心依然是把异常挡在 deleter 边界内。
7. 一句话贯穿条款8：析构函数是兜底，不是业务出口
写到这里，我想把条款8的“神”再浓缩一下：析构函数是一个对象生命周期里最后一刻执行的动作，它必须假设外部一切已经不可靠——资源可能已坏，异常可能已在传播。对一个“只负责处理不可靠环境”的函数，你是不能在外层再给它加一层错误处理通道的。 所以唯一合理的设计就是尽量让它在内部消化所有错误，确保它自身不会成为崩溃源。
如果你在写资源管理类或者任何带清理逻辑的类，建议每次写完析构函数后问自己三个问题：
- 如果析构函数里这个操作失败了，用户能不能感知到？
- 如果这个操作失败了，会不会导致进程直接被 terminate？
- 用户有没有机会在对象销毁之前，显式执行这个操作并捕获异常？
第一个问题的答案如果是“需要感知”，那就必须提供显式接口；第二个问题的答案如果“是”，那立刻改代码；第三个问题的答案如果是“否”，那说明你的 API 设计可能存在隐患，需要再补一个手动释放接口。
我个人在实际项目里，已经把“别让异常逃离析构函数”内化成了肌肉记忆。写任何 ~Foo() 时，脑子里会自动扫一遍函数体内的每一个调用：它会不会 throw？如果会，我包没包住？如果没包住，它会不会和现有异常叠加？这套流程只要走一遍，就能挡掉大量看似微小、实则致命的 bug。
最后再分享一个排查技巧小提示：如果你的程序在退出阶段、析构阶段突然 SIGABRT，翻译成 exit code 134，或者看到 terminate called after throwing an instance of ...，但代码里却没有明显的顶层 throw，那基本可以确定是某个析构函数、deleter 或者全局对象清理路径上把异常漏了出来。优先在这些地方加日志，并且把异常信息打印出来，定位会快得多。
条款8短，但它背后的工程哲学很深。理解它，不只是在析构函数里加 try-catch，而是在设计资源管理类时，把“清理”本身当成一个重要的业务流程来设计。这样，你的 C++ 代码才能在异常满天飞的世界里，稳稳地跑到最后。