如果您不应该在析构函数中抛出异常，那么如何处理其中的错误？

Question

大多数人说永远从析构函数中抛出异常 - 这样做会导致未定义的行为。 Stroustrup 指出“向量析构函数显式地调用每个元素的析构函数。这意味着如果元素析构函数抛出异常，向量析构就会失败......确实没有好的方法来防止析构函数抛出异常，因此，库不保证元素析构函数是否抛出“（来自附录 E3.2）。

这篇文章似乎另有说法 - 抛出析构函数或多或少少一点还好。

所以我的问题是 - 如果从析构函数中抛出导致未定义的行为，您如何处理析构函数期间发生的错误？

如果在清理操作期间发生错误，您会忽略它吗？ 如果这是一个可以在堆栈中处理但不能在析构函数中处理的错误，那么从析构函数中抛出异常是否有意义？

显然，此类错误很少见，但也有可能发生。

Answer 1

所以我的问题是 - 如果从析构函数抛出会导致
未定义的行为，如何处理期间发生的错误
析构函数？

主要问题是：你不能失败。 失败到底意味着什么？ 如果向数据库提交事务失败，并且失败（无法回滚），我们数据的完整性会发生什么情况？

由于析构函数是为正常和异常（失败）路径调用的，因此它们本身不能失败，否则我们就会“失败”。

这是一个概念上的困难问题，但解决方案通常就是找到一种方法来确保失败不会失败。 例如，数据库可能会在提交到外部数据结构或文件之前写入更改。 如果事务失败，则文件/数据结构可以被丢弃。 然后它必须确保从外部结构/文件提交更改是一个不会失败的原子事务。

务实的解决方案也许只是确保
失败中的失败在天文数字上是不可能的，因为制造东西
在某些情况下，不可能失败几乎是不可能的。

对我来说最合适的解决方案是以一种使清理逻辑不会失败的方式编写非清理逻辑。 例如，如果您想创建一个新的数据结构以清理现有的数据结构，那么您可能会寻求提前创建该辅助结构，以便我们不再需要在析构函数内创建它。

诚然，这说起来容易做起来难，但这是我认为唯一真正正确的方法。 有时我认为应该有能力为正常执行路径编写单独的析构函数逻辑，远离异常路径，因为有时析构函数感觉有点像通过尝试处理这两者而承担了双重责任（一个例子是需要显式解雇的作用域守卫） ；如果他们能够区分特殊的破坏路径和非特殊的破坏路径，他们就不需要这样做）。

最终的问题仍然是我们不能失败，而且这是一个在所有情况下都需要完美解决的概念设计难题。 如果您不要过于陷入复杂的控制结构（其中有大量相互交互的微小对象），而是以稍微庞大的方式对您的设计进行建模（例如：带有析构函数的粒子系统来破坏整个粒子），那么它确实会变得更容易系统，而不是每个粒子一个单独的非平凡析构函数）。 当您在这种较粗糙的级别上对设计进行建模时，需要处理的重要析构函数就会减少，并且通常还可以承担确保析构函数不会失败所需的任何内存/处理开销。

最简单的解决方案之一自然是减少使用析构函数。 在上面的粒子示例中，也许在销毁/移除粒子时，应该执行一些可能因任何原因而失败的操作。 在这种情况下，您可以在删除粒子时让粒子系统完成所有操作，而不是通过粒子的 dtor 调用此类逻辑（可以在异常路径中执行）。 移除粒子可能总是在非异常路径中完成。 如果系统被破坏，也许它可以只清除所有粒子，而不必担心可能失败的单个粒子移除逻辑，而可能失败的逻辑仅在粒子系统正常执行期间移除一个或多个粒子时执行。

如果您避免使用不平凡的析构函数处理大量微小对象，通常会出现类似的解决方案。 你可能会陷入混乱，似乎几乎不可能出现异常安全，那就是当你确实陷入许多微小的对象，而这些对象都有不平凡的 dtors 时。

如果任何指定它的东西（包括应该继承其基类的 noexcept 规范的虚函数）尝试调用任何可能抛出的东西，那么如果 nothrow/noexcept 实际上转换为编译器错误，那将会有很大帮助。 这样，如果我们实际上无意中编写了一个可能抛出异常的析构函数，我们就能够在编译时捕获所有这些东西。

Answer 2

我们必须在这里区分，而不是盲目遵循针对具体情况的一般建议。

请注意，以下忽略对象容器的问题以及面对容器内对象的多个d'tors时该怎么办。 （它可以被部分忽略，因为有些对象不适合放入容器中。）

当我们将类分成两种类型时，整个问题就变得更容易思考。 类 dtor 可以有两种不同的职责：

• (R) 释放语义（又名释放该内存）
• (C) 提交语义（又名刷新文件到磁盘）

如果我们查看以这种方式提问，那么我认为可以说（R）语义永远不应该导致 dtor 的异常，因为 a）我们对此无能为力，b）许多免费资源操作甚至不提供错误检查，例如 void free(void* p);。

具有 (C) 语义的对象，例如需要成功刷新其数据的文件对象或在 dtor 中进行提交的（“范围保护”）数据库连接，属于不同类型：我们可以对错误采取一些措施（在应用程序级别），我们真的不应该继续下去，就好像什么都没发生一样。

如果我们遵循 RAII 路线并允许在其 d'tors 中具有 (C) 语义的对象，我认为我们还必须允许此类 d'tors 可能抛出的奇怪情况。 因此，您不应该将此类对象放入容器中，并且如果 commit-dtor 在另一个异常处于活动状态时抛出，程序仍然可以 terminate()。

---

关于错误处理（提交/回滚语义）和异常，Andrei Alexandrescu 发表了一篇很好的演讲：C++/声明式控制流中的错误处理（位于 NDC 2014)

在详细信息中，他解释了 Folly 库如何实现 UncaughtExceptionCounter 为他们的 ScopeGuard 工具。

（我应该注意到其他人也有类似的想法。）

虽然谈话的重点不是从作为一名作者，它展示了一个现在可以用来消除何时从 d'tor 抛出的问题。

在未来中，可能为此提供标准功能，请参阅N3614、 和 有关它的讨论。

更新 '17：C++17 std 功能为 std::uncaught_exceptions 事实证明。 我将快速引用 cppref 文章：

注释

使用int-返回uncaught_exceptions的示例是……首先
创建一个守卫对象并记录未捕获异常的数量
在它的构造函数中。 输出由守卫对象执行
析构函数，除非 foo() 抛出（在这种情况下，未捕获的数量
析构函数中的异常大于构造函数中的异常
观察到）

Answer 3

它很危险，但从可读性/代码可理解性的角度来看，它也没有意义。

你要问的是在这种情况下

int foo()
{
   Object o;
   // As foo exits, o's destructor is called
}

应该用什么来捕获异常呢？ foo 的调用者应该吗？ 或者 foo 应该处理它吗？ 为什么 foo 的调用者应该关心 foo 内部的某些对象？ 语言可能有某种方式来定义它，使其有意义，但它会变得不可读且难以理解。

更重要的是，Object的内存去了哪里？ 对象拥有的内存去了哪里？ 它是否仍然被分配（表面上是因为析构函数失败）？ 还要考虑该对象位于堆栈空间中，因此无论如何它显然都消失了。

那么考虑这种情况，

class Object
{ 
   Object2 obj2;
   Object3* obj3;
   virtual ~Object()
   {
       // What should happen when this fails? How would I actually destroy this?
       delete obj3;

       // obj 2 fails to destruct when it goes out of scope, now what!?!?
       // should the exception propogate? 
   } 
};

当obj3的删除失败时，我该如何以保证不失败的方式实际删除呢？ 这是我的记忆该死！

现在考虑在第一个代码片段中，Object 会自动消失，因为它位于堆栈上，而 Object3 位于堆上。 由于指向 Object3 的指针消失了，您就可以了。 你有内存泄漏。

现在，一种安全的做法如下

class Socket
{
    virtual ~Socket()
    {
      try 
      {
           Close();
      }
      catch (...) 
      {
          // Why did close fail? make sure it *really* does close here
      }
    } 

};

另请参阅此常见问题解答< /a>

Answer 4

关于从析构函数中抛出，真正要问自己的问题是“调用者可以用它做什么？” 实际上，您可以对异常做一些有用的事情，以抵消从析构函数抛出异常所造成的危险吗？

如果我销毁一个 Foo 对象，并且 Foo 析构函数抛出异常，我可以合理地用它做什么？ 我可以记录它，也可以忽略它。 就这样。 我无法“修复”它，因为 Foo 对象已经消失了。 最好的情况是，我记录异常并继续，就像什么都没发生一样（或终止程序）。 这真的值得通过从析构函数中抛出来潜在地导致未定义的行为吗？

Answer 5

来自 C++ 的 ISO 草案 (ISO/IEC JTC 1/SC 22 N 4411)

因此，析构函数通常应该捕获异常，而不是让它们从析构函数中传播出去。

3 为从 try 块到 throw 的路径上构造的自动对象调用析构函数的过程
表达式称为“堆栈展开”。 [ 注意：如果在堆栈展开期间调用的析构函数以
异常，std::terminate 被调用（15.5.1）。 所以析构函数通常应该捕获异常而不是让
它们从析构函数中传播出来。 ——尾注]

Answer 6

我属于认为在析构函数中抛出“范围保护”模式在许多情况下都很有用的小组 - 特别是对于单元测试。 但是，请注意，在 C++11 中，抛出析构函数会导致调用 std::terminate，因为析构函数是用 noexcept 隐式注释的。

Andrzej Krzemieński 有一篇关于抛出析构函数主题的精彩文章：

• https ://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/

他指出C++11有一种机制可以覆盖析构函数的默认noexcept :

在 C++11 中，析构函数隐式指定为 noexcept。 即使您没有添加任何规范并像这样定义析构函数：

 类 MyType { 
        公共：〜MyType（）{抛出异常（）;   } // ... 
    }; 
  

编译器仍然会无形地向析构函数添加规范noexcept。 这意味着当你的析构函数抛出异常时，即使不存在双异常情况，std::terminate 也会被调用。 如果您确实决定允许析构函数抛出异常，则必须明确指定这一点； 您有三个选择：

• 将析构函数明确指定为 noexcept(false),
• 从另一个已将其析构函数指定为 noexcept(false) 的类继承您的类。
• 在您的类中放置一个已将其析构函数指定为 noexcept(false) 的非静态数据成员。

最后，如果您确实决定抛出析构函数，则应该始终注意双重异常的风险（由于异常而在堆栈展开时抛出）。 这会导致调用 std::terminate ，而这很少是您想要的。 为了避免这种行为，您可以简单地使用 std::uncaught_exception() 在抛出新异常之前检查是否已经存在异常。

因此，一个完整的工作示例可能如下所示：

class ThrowsOnDtor {
  int _uncaught_count = std::uncaught_exceptions();
public:
  ~ThrowsOnDtor() noexcept(false) {
    if (std::uncaught_exceptions() == _uncaught_count) // unchanged
      throw std::runtime_error("from dtor");
    else
      std::cerr << "Avoided throwing while unwinding the stack" << std::endl;
  }
};

Answer 7

作为对主要答案的补充，这些答案很好，全面且准确，我想对您引用的文章发表评论 - 那篇文章说“在析构函数中抛出异常并不是那么糟糕”。

本文采用“抛出异常的替代方案是什么”这一行，并列出了每种替代方案的一些问题。 这样做后，得出的结论是，因为我们找不到没有问题的替代方案，所以我们应该继续抛出异常。

问题在于，它列出的替代方案中的任何问题都不如异常行为那么糟糕，让我们记住，异常行为是“程序的未定义行为”。 作者的一些反对意见包括“审美丑陋”和“鼓励不良风格”。 现在你更想要哪一个？ 一个风格不好的程序，或者表现出未定义行为的程序？

Answer 8

您的析构函数可能在其他析构函数链内执行。 引发直接调用者未捕获的异常可能会使多个对象处于不一致状态，从而导致比忽略清理操作中的错误更多的问题。

Answer 9

其他人都解释了为什么抛出析构函数是可怕的......你能做些什么呢？ 如果您正在执行的操作可能会失败，请创建一个单独的公共方法来执行清理并可以引发任意异常。 在大多数情况下，用户会忽略这一点。 如果用户想要监视清理的成功/失败，他们可以简单地调用显式清理例程。

例如：

class TempFile {
public:
    TempFile(); // throws if the file couldn't be created
    ~TempFile() throw(); // does nothing if close() was already called; never throws
    void close(); // throws if the file couldn't be deleted (e.g. file is open by another process)
    // the rest of the class omitted...
};

Answer 10

问：所以我的问题是这样的 - 如果
从析构函数抛出会导致
未定义的行为，你如何处理
析构函数期间发生的错误？

答：有几种选择：

1. 让异常从析构函数中流出，不管其他地方发生了什么。 这样做时要注意（甚至担心）std::terminate 可能会随之而来。

2. 永远不要让异常从析构函数中流出。 如果可以的话，可能会写入日志，一些大红色的错误文本。

3. 我的最爱：如果std::uncaught_exception返回false，让你的异常流出。 如果它返回 true，则返回到日志记录方法。

但是投入 d'tors 是好事吗？

我同意上面的大部分内容，即最好在析构函数中避免抛出，如果可以的话。 但有时你最好接受它可能发生的事实，并妥善处理它。 我选上面3个。

在一些奇怪的情况下，从析构函数中抛出实际上是一个好主意。
就像“必须检查”错误代码一样。 这是从函数返回的值类型。 如果调用者读取/检查包含的错误代码，则返回的值将默默地破坏。
但是，如果返回值超出范围时尚未读取返回的错误代码，会从其析构函数中抛出一些异常。

Answer 11

设置警报事件。 通常，警报事件是在清理对象时通知失败的更好形式

Answer 12

从析构函数中抛出异常永远不会导致未定义的行为。

将异常抛出析构函数的问题是，在处理未捕获的异常时（在创建异常对象之后，直到异常激活的处理程序完成），成功创建的对象的析构函数由异常处理调用，这些对象的作用域正在离开机制; 并且，如果在处理未捕获的异常时调用的析构函数中的此类附加异常中断了对未捕获的异常的处理，则会导致调用 std::terminate （另一种情况是 std::exception code> 被调用的原因是异常不被任何处理程序处理，但这与任何其他函数一样，无论它是否是析构函数）。

---

如果正在处理未捕获的异常，您的代码永远不知道附加异常是否会被捕获，或者是否会存档未捕获的异常处理机制，因此永远不知道抛出是否安全。

不过，可以知道处理未捕获的异常正在进行中（ https:// en.cppreference.com/w/cpp/error/uncaught_exception），因此您可以通过检查条件来矫枉过正，并仅在情况并非如此时才抛出（在某些情况下，它不会抛出安全的）。

但在实践中，这种分成两种可能的行为是没有用的——它只是无助于你制作一个设计良好的程序。

---

如果您抛出析构函数而忽略是否正在进行未捕获的异常处理，为了避免可能调用 std::terminate，您必须保证在对象的生命周期中抛出的所有异常都可能发生。在开始销毁对象之前，会捕获从析构函数抛出的异常。
它的用途相当有限； 您几乎无法使用所有可以合理地允许以这种方式从其析构函数中抛出的类； 仅对某些类允许此类例外以及对这些类的使用进行如此严格的限制的组合也妨碍了设计良好的程序。

Answer 13

与构造函数不同的是，在构造函数中抛出异常可以是指示对象创建成功的有用方法，而析构函数中不应抛出异常。

当在堆栈展开过程中从析构函数引发异常时，就会出现此问题。 如果发生这种情况，编译器就会陷入不知道是否继续堆栈展开过程或处理新异常的情况。 最终的结果是你的程序将立即终止。

因此，最好的做法就是完全避免在析构函数中使用异常。 相反，将消息写入日志文件。

Answer 14

Martin Ba（上图）走在正确的轨道上——您以不同的方式构建 RELEASE 和 COMMIT 逻辑。

对于发布：

您应该吃掉任何错误。 您正在释放内存、关闭连接等。系统中的其他任何人都不应该再次看到这些东西，并且您正在将资源交还给操作系统。 如果您看起来需要在这里进行真正的错误处理，则可能是对象模型中设计缺陷的结果。

对于提交：

这是您需要与 std::lock_guard 等为互斥体提供的同类 RAII 包装对象的地方。 对于这些，您根本不需要将提交逻辑放入 dtor 中。 您有一个专用的 API，然后是包装对象，RAII 将其提交到他们的 dtor 中并在那里处理错误。 请记住，您可以在析构函数中捕获异常； 发布它们是致命的。 这还允许您通过构建不同的包装器（例如 std::unique_lock 与 std::lock_guard）来实现策略和不同的错误处理，并确保您不会忘记调用提交逻辑 - 这是唯一的中间方法首先将其放入 dtor 的合理理由。

Answer 15

显然，在非常特殊的情况下，例如下面的场景，您可以在析构函数中抛出异常并捕获它以正确处理它。

代码：

#include <iostream>
#include <unordered_map>

class Foo
{
    public:
    Foo(int i)
    {
        std::cout << "Created\n";
    }
    
    ~Foo() noexcept(false)
    {
        throw std::runtime_error("I am an exception thrown from the destructor!");
    }
};

std::unordered_map<std::string, Foo> MyList;

int main() {
    MyList.emplace("foo", 1);
    try
    {
        MyList.erase("foo");
    }
    catch (const std::exception& e)
    {
        std::cerr << e.what();
    }

    return 0;
}

输出：

Created
I am an exception thrown from the destructor!

Answer 16

我目前遵循的政策（很多人都在说），类不应主动从其析构函数中抛出异常，而应提供一个公共“关闭”方法来执行可能失败的操作......

但我确实相信容器类型类的析构函数（如向量）不应掩盖从它们包含的类抛出的异常。 在这种情况下，我实际上使用了递归调用自身的“free/close”方法。 是的，我递归地说。 这种疯狂是有办法的。 异常传播依赖于堆栈：如果发生单个异常，则剩余的析构函数仍将运行，并且一旦例程返回，待处理的异常将传播，这很棒。 如果发生多个异常，则（取决于编译器）要么传播第一个异常，要么程序终止，这是可以的。 如果发生太多异常，导致递归溢出堆栈，那么就会出现严重错误，有人会发现它，这也没关系。 就我个人而言，我宁愿错误被爆发，也不愿被隐藏、秘密和阴险。

关键是容器保持中立，并且由所包含的类来决定它们在从析构函数中抛出异常方面是否行为不当。

Answer 17

从析构函数中抛出异常是危险的。
如果另一个异常已经传播，应用程序将终止。
但是说“终止”是大多数编译器的一个非常明确的行为，因此它几乎从来不是“未定义的行为”（取决于编译器）。

#include <iostream>

class Bad
{
    public:
        // Added the noexcept(false) so the code keeps its original meaning.
        // Post C++11 destructors are by default `noexcept(true)` and
        // this will (by default) call terminate if an exception is
        // escapes the destructor.
        //
        // But this example is designed to show that terminate is called
        // if two exceptions are propagating at the same time.
        ~Bad() noexcept(false)
        {
            throw 1;
        }
};
class Bad2
{
    public:
        ~Bad2()
        {
            throw 1;
        }
};


int main(int argc, char* argv[])
{
    try
    {
        Bad   bad;
    }
    catch(...)
    {
        std::cout << "Print This\n";
    }

    try
    {
        if (argc > 3)
        {
            Bad   bad; // This destructor will throw an exception that escapes (see above)
            throw 2;   // But having two exceptions propagating at the
                       // same time causes terminate to be called.
        }
        else
        {
            Bad2  bad; // The exception in this destructor will
                       // cause terminate to be called.
        }
    }
    catch(...)
    {
        std::cout << "Never print this\n";
    }

}

这基本上可以归结为：

任何危险的事情（即可能引发异常）都应该通过公共方法（不一定是直接的）完成。 然后，类的用户可以通过使用公共方法并捕获任何潜在的异常来处理这些情况。

然后，析构函数将通过调用这些方法来结束对象（如果用户没有明确执行此操作），但抛出的任何异常都会被捕获并丢弃（在尝试解决问题之后）。

因此，实际上您将责任转移给了用户。 如果用户能够纠正异常，他们将手动调用适当的函数并处理任何错误。 如果对象的用户不担心（因为对象将被销毁），那么析构函数就可以处理事务。

示例：

std::fstream

close() 方法可能会引发异常。
如果文件已打开，析构函数将调用 close()，但确保任何异常不会传播到析构函数之外。

因此，如果文件对象的用户想要对与关闭文件相关的问题进行特殊处理，他们将手动调用 close() 并处理任何异常。 另一方面，如果他们不在乎，那么析构函数将被留下来处理这种情况。

Scott Meyers 在他的书“Effective C++”中有一篇关于该主题的精彩文章

编辑：

显然也在“更有效的 C++”中
第 11 项：防止异常离开析构函数

Answer 18

抛出析构函数可能会导致崩溃，因为该析构函数可能被称为“堆栈展开”的一部分。
堆栈展开是抛出异常时发生的过程。
在这个过程中，从“try”开始直到抛出异常为止所有被压入堆栈的对象都将被终止 -> 他们的析构函数将被调用。
在此过程中，不允许再次抛出异常，因为不可能一次处理两个异常，因此，这将引发对 abort() 的调用，程序将崩溃，控制权将返回到操作系统。