std::set_terminate指定处理器未调用abort()时的程序行为咨询

嘿，这个问题问得相当精准，刚好触及了C++异常处理里一个容易踩坑的细节！让我给你掰扯清楚：

首先先回顾下背景：std::terminate()确实会在几种关键场景下被触发，比如未捕获的异常、在已有异常传播时析构函数又抛出异常、noexcept修饰的函数抛出了异常等等。默认情况下，它会调用std::abort()直接终止程序，但我们可以通过std::set_terminate()替换成自定义的处理器。

那核心问题来了：如果自定义的处理器不调用abort()（或者exit()、quick_exit()这类能终止程序的函数），程序会怎么样？

答案是：行为完全未定义（Undefined Behavior）！

C++标准明确要求，std::terminate_handler类型的函数必须不能返回——也就是说，你的自定义处理器必须最终触发程序终止，不能执行完所有代码后回到调用std::terminate()的地方。如果你的处理器真的返回了，那接下来发生什么就全看编译器和操作系统的心情了：可能直接崩溃，可能陷入死循环，可能打印一堆乱码，甚至可能看似“正常”继续执行（但这绝对是危险的，因为此时程序状态已经完全失控）。

而且，系统不会默认帮你补充调用abort()。标准里没有这个兜底逻辑，因为当std::terminate()被调用时，程序已经处于极其不稳定的状态——比如未捕获异常意味着控制流完全偏离预期，析构函数抛异常则破坏了异常传播的规则，此时程序根本没有继续安全执行的基础。

举个简单的反面例子，你可以试试这段代码：

#include <exception>
#include <iostream>

void my_custom_terminate() {
    std::cout << "Oh no, we're terminating!" << std::endl;
    // 这里故意不调用abort()或exit()
}

int main() {
    std::set_terminate(my_custom_terminate);
    throw 42; // 未捕获异常，触发std::terminate()
}

在不同编译器下运行这段代码，你会得到完全不同的结果：GCC可能直接触发段错误，VS可能弹出系统错误对话框，甚至有些环境下可能会“假装”继续运行，但后续的所有操作都不可靠。

所以总结一下：自定义std::terminate处理器时，一定要确保它最终调用abort()、exit()这类终止函数，否则程序行为会完全失控，没有任何标准可依。

内容的提问来源于stack exchange，提问作者andreipb