向C++异常类流式传输数据是否有风险？两种实现对比

咱们来聊聊你问的这个C++异常流式写法的问题——这种写法看着简洁酷炫，但藏着不少实打实的坑，远不如先构造字符串再抛出的方式靠谱。

先回顾下你给出的两种写法：
第一种流式抛出：

throw my_exception() << "The error " << error_code << " happened because of " << reasons;

第二种先拼接再抛出：

std::stringstream s;
s << "The error " << error_code << " happened because of " << reasons;
throw my_exception(s.str());

最致命的风险：直接触发程序终止 #

第一种写法的核心问题在于流式操作可能在异常抛出的过程中再次抛出异常：
当执行throw my_exception() << ...时，流程是先构造临时的my_exception对象，再依次调用operator<<拼接数据。如果你的operator<<实现里涉及内存分配（比如用std::string存储内容，扩容时触发std::bad_alloc），就会在当前throw的处理过程中抛出新异常。

根据C++标准，要是在栈展开阶段（也就是处理当前异常的过程中）出现未被捕获的新异常，程序会直接调用std::terminate()终止运行——连错误日志都来不及输出，直接崩掉。

反观第二种写法：字符串拼接是在正常代码路径里完成的，如果这时候抛出异常（比如内存不足），你可以提前捕获它，做降级处理（比如用默认错误消息、记录日志），而不是直接让程序挂掉。

异常状态的不完整性 #

退一步说，就算operator<<没触发程序终止，要是某一步拼接失败，之前写入异常对象的数据是残缺的，但此时程序已经进入异常流程，你大概率拿不到这部分不完整的错误信息。而第二种写法里，只有当整个字符串拼接完成后才会抛出异常，异常对象的错误信息是完整可靠的。

效率问题其实是次要的 #

你提到的“效率低下”其实不是核心矛盾——两种方式本质都是字符串拼接，性能差异微乎其微。真正要警惕的是上面说的安全性风险。

总结 #

第一种流式抛出异常的写法存在严重的程序终止风险，除非你能100%保证operator<<的实现绝对不会抛出任何异常（比如用固定大小的静态缓冲区，且不会溢出），否则强烈建议用第二种先完成字符串拼接再抛出的写法。

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