boost::asio::ip::tcp::iostream开启异常后客户端断开触发std::terminate问题

直接触发逻辑 #

客户端断开连接后，服务端下一次执行client << "x\n"时，底层TCP写操作会收到连接重置错误，触发流状态位更新。
你预先通过client.exceptions(...)配置了异常掩码，覆盖了failbit、badbit等位，因此当basic_ios::clear()被调用更新流状态时，会因状态与掩码匹配抛出std::ios_failure异常。

触发terminate的核心原因 #

根据GDB调用栈，抛出异常的clear()函数是在std::ostream::sentry的析构函数内部调用的。C++标准规定所有析构函数默认隐式为noexcept，即不允许抛出异常。如果noexcept函数内部抛出异常，程序会直接调用std::terminate()终止，完全不会进入外层的try-catch块捕获异常。
注释掉exceptions()调用时程序可以正常退出，是因为此时clear()只会静默设置状态位，不会抛出异常，sentry析构正常返回，operator<<返回的流对象转换为bool值时为false，循环正常退出并输出"Completed"。

• 冗余的eofbit配置：异常掩码中加入的std::ios_base::eofbit仅在读取流遇到EOF时才会被设置，对于纯写操作的服务端来说完全无用，属于多余配置。
• 对流异常抛出时机的误解：默认流操作的异常只会在操作返回点抛出，但实际上负责触发异常的clear()函数可能在任意上下文被调用，包括临时RAII对象（如这里的ostream::sentry）的析构函数中。当异常掩码覆盖了会在析构中被设置的状态位时，就会触发noexcept析构的异常逃逸，直接终止程序。
• 未适配STL实现的行为差异：当前使用的libstdc++实现中，流状态的更新动作发生在sentry析构阶段，这种行为不符合“写操作返回时抛错”的预期流程，不同STL实现的状态更新时机可能不同。

如果需要使用异常处理写错误，可先关闭流的自动刷新标志，避免在sentry析构时触发flush错误：

client << std::nounitbuf; // 关闭每次输出后自动flush的行为
client.exceptions(std::ios_base::failbit | std::ios_base::badbit); // 移除冗余的eofbit

若仍出现析构抛异常的问题，建议改为手动检查client.fail()/client.bad()状态位处理错误，不要依赖异常机制处理Socket IO的错误场景。 #

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