是否应使用std::uncaught_exceptions()决定析构函数中是否抛出异常？

我有一个类，构造函数会调用驱动程序，析构函数负责执行对应的终止/释放驱动程序的调用。这些调用有可能失败，麻烦就出在析构函数执行时的这类失败上。

我清楚析构函数应避免抛出异常的常规规则——如果在栈展开过程中抛出异常，程序会直接终止。但我不想随便“吞掉”这些错误而不做任何报告，要是有可行办法的话。

那下面这段代码的写法是否合理、符合C++惯用风格？

~MyClass() noexcept(false) {
    auto result = something_which_may_fail_but_wont_throw();
    if (is_error(result) and std::uncaught_exceptions() == 0) {
        throw some_exception(result);
    }
}

注：该类无法访问标准输出/错误流，也没有日志功能。

回答 #

这种写法是一种可行的妥协方案，但算不上C++中的“惯用写法”，需要权衡它的优缺点：

优点 #

• 避免静默吞掉错误：当没有未捕获异常（即析构函数正常执行，非栈展开阶段）时，错误会通过抛出异常暴露，不会被悄悄忽略。
• 守住核心安全底线：通过std::uncaught_exceptions() == 0的判断，确保不会在栈展开过程中抛出异常，避免了程序直接终止的风险。

缺点 #

• 违背常规认知：C++中析构函数默认是noexcept(true)，显式声明noexcept(false)会让其他开发者感到意外，增加代码的理解成本。
• 错误覆盖有局限：一旦处于栈展开阶段，错误还是会被吞掉——虽然这是为了安全，但依然存在无法报告错误的场景。
• 异常设计需谨慎：抛出的异常类型必须合理，不能是过于底层的错误类型，否则上层调用者可能无法妥善处理。

替代优化思路（若有调整空间） #

• 增加显式资源释放方法：给类添加close()或release()这类显式方法，让用户主动调用释放资源，在该方法中可以自由抛出异常报告错误；析构函数仅作为兜底，即使释放失败也只做最小化处理（比如标记错误但不抛出）。这是更符合C++惯用的“显式资源管理”思路。
• 存储内部错误状态：在类内部记录析构是否失败的状态，提供get_last_error()之类的接口让用户主动查询，但这种方式依赖用户主动检查，仍有被忽略的可能。

总结 #

如果当前确实没有其他错误报告渠道（比如无法使用日志、标准流），你给出的写法是一个可以接受的权宜之计；但从长期维护和代码可读性来看，显式的资源释放方法是更清晰、更符合C++惯用风格的方案。

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