我的问题是，如果从析构函数抛出会导致 未定义的行为，如何处理过程中发生的错误 析构函数?

主要的问题是:你不能失败到失败。失败到底意味着什么?如果将事务提交到数据库失败，并且事务未能失败(回滚失败)，那么数据的完整性会发生什么变化?

由于析构函数在正常路径和异常(失败)路径上都被调用，它们本身不能失败，否则我们就是“失败”。

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

务实的解决办法也许就是确保 一次又一次的失败在天文学上是不可能的，因为做东西 在某些情况下，失败几乎是不可能的。

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

This is all much easier said than done, admittedly, but it's the only really proper way I see to go about it. Sometimes I think there should be an ability to write separate destructor logic for normal execution paths away from exceptional ones, since sometimes destructors feel a little bit like they have double the responsibilities by trying to handle both (an example is scope guards which require explicit dismissal; they wouldn't require this if they could differentiate exceptional destruction paths from non-exceptional ones).

Still the ultimate problem is that we can't fail to fail, and it's a hard conceptual design problem to solve perfectly in all cases. It does get easier if you don't get too wrapped up in complex control structures with tons of teeny objects interacting with each other, and instead model your designs in a slightly bulkier fashion (example: particle system with a destructor to destroy the entire particle system, not a separate non-trivial destructor per particle). When you model your designs at this kind of coarser level, you have less non-trivial destructors to deal with, and can also often afford whatever memory/processing overhead is required to make sure your destructors cannot fail.

And that's one of the easiest solutions naturally is to use destructors less often. In the particle example above, perhaps upon destroying/removing a particle, some things should be done that could fail for whatever reason. In that case, instead of invoking such logic through the particle's dtor which could be executed in an exceptional path, you could instead have it all done by the particle system when it removes a particle. Removing a particle might always be done during a non-exceptional path. If the system is destroyed, maybe it can just purge all particles and not bother with that individual particle removal logic which can fail, while the logic that can fail is only executed during the particle system's normal execution when it's removing one or more particles.

如果避免使用非平凡析构函数处理大量小对象，通常会出现这样的解决方案。当你被大量的小对象纠缠在一起时，你可能会陷入混乱，似乎不可能是异常安全的，这些小对象都有非平凡的dtor。

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

我所在的小组认为，在析构函数中加入“作用域保护”模式在许多情况下都很有用——特别是对于单元测试。但是，要注意，在c++ 11中，抛出析构函数会导致调用std::terminate，因为析构函数隐式地用noexcept注释。

Andrzej krzemiezynski有一篇关于抛出析构函数的文章:

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

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

In C++11, a destructor is implicitly specified as noexcept. Even if you add no specification and define your destructor like this: class MyType { public: ~MyType() { throw Exception(); } // ... }; The compiler will still invisibly add specification noexcept to your destructor. And this means that the moment your destructor throws an exception, std::terminate will be called, even if there was no double-exception situation. If you are really determined to allow your destructors to throw, you will have to specify this explicitly; you have three options: Explicitly specify your destructor as noexcept(false), Inherit your class from another one that already specifies its destructor as noexcept(false). Put a non-static data member in your class that already specifies its destructor as noexcept(false).

最后，如果您决定抛出析构函数，则应该始终注意双异常的风险(在堆栈因异常而被unwind时抛出)。这将导致调用std::terminate，这很少是您想要的。为了避免这种行为，你可以使用std::uncaught_exception()在抛出一个新的异常之前检查是否已经有一个异常。

c++的ISO草案(ISO/IEC JTC 1/SC 22 N 4411)

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

为在try块到throw-的路径上构造的自动对象调用析构函数的过程 表达式称为“堆栈unwind”。[注意:如果在堆栈展开期间调用析构函数退出 异常，std::terminate被调用(15.5.1)。因此，析构函数通常应该捕获异常，而不是let 它们从析构函数中传播出去。-结束注]

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

#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:防止异常离开析构函数

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

例如:

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...
};

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.