从析构函数抛出异常是危险的。 如果另一个异常已经在传播，则应用程序将终止。

#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 Myers在他的书《Effective c++》中有一篇关于这个主题的优秀文章。

编辑:

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

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

A:有几种选择:

让异常流出析构函数，而不管其他地方发生了什么。在这样做的时候，要意识到(甚至害怕)std::terminate可能会随之而来。 永远不要让异常从析构函数流出。可能是写一个日志，一些大红色坏文本，如果可以的话。 我的最爱:如果std::uncaught_exception返回false，让你的异常流出。如果返回true，则退回到日志记录方法。

但加进d'tors好吗?

我同意上面的大部分观点，在析构函数中最好避免抛出，因为它可以在析构函数中抛出。但有时你最好接受它的发生，并妥善处理。我选择上面的3。

在一些奇怪的情况下，从析构函数抛出实际上是个好主意。 比如“必须检查”错误代码。这是一个从函数返回的值类型。如果调用者读取/检查包含的错误代码，返回值将静默销毁。 但是，如果返回值超出作用域时还没有读取返回的错误代码，则它将从析构函数抛出一些异常。

你的析构函数可能在其他析构函数链中执行。抛出未被立即调用者捕获的异常可能会使多个对象处于不一致的状态，从而导致更多的问题，而不是在清理操作中忽略错误。

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

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

问题在于，它列出的所有问题都没有异常行为那么糟糕，让我们记住，异常行为是“程序的未定义行为”。作者的一些反对意见包括“美学上的丑陋”和“鼓励糟糕的风格”。现在你想要哪一个?一个风格糟糕的程序，还是一个表现出未定义行为的程序?

关于从析构函数抛出，真正要问自己的问题是“调用者可以用它做什么?”你是否真的可以对异常做一些有用的事情，来抵消从析构函数抛出的危险?

如果我销毁了一个Foo对象，而Foo析构函数抛出了一个异常，我可以合理地对它做什么?我可以记录，也可以忽略。这是所有。我不能“修复”它，因为Foo对象已经消失了。最好的情况是，我记录异常并继续，就像什么都没有发生一样(或者终止程序)。这真的值得通过从析构函数抛出来潜在地引起未定义的行为吗?

Martin Ba(上图)在正确的轨道上——你为RELEASE和COMMIT逻辑构建了不同的架构。

发布:

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

提交:

This is where you want the same kind of RAII wrapper objects that things like std::lock_guard are providing for mutexes. With those you don't put the commit logic in the dtor AT ALL. You have a dedicated API for it, then wrapper objects that will RAII commit it in THEIR dtors and handle the errors there. Remember, you can CATCH exceptions in a destructor just fine; its issuing them that's deadly. This also lets you implement policy and different error handling just by building a different wrapper (e.g. std::unique_lock vs. std::lock_guard), and ensures you won't forget to call the commit logic- which is the only half-way decent justification for putting it in a dtor in the 1st place.