大多数人说永远不要从析构函数抛出异常——这样做会导致未定义的行为。Stroustrup指出，“vector析构函数显式地为每个元素调用析构函数。这意味着如果元素析构函数抛出，则vector销毁失败…实际上没有很好的方法来防止析构函数抛出异常，因此标准库不保证元素析构函数是否抛出”(摘自附录E3.2)。
这篇文章似乎不是这么说的——抛出析构函数或多或少是可以的。
所以我的问题是，如果从析构函数抛出导致未定义的行为，你如何处理析构函数期间发生的错误?
如果在清理操作期间发生错误，您会忽略它吗?如果它是一个可以在堆栈中处理但不能在析构函数中处理的错误，那么从析构函数抛出异常难道没有意义吗?
显然，这种错误很少见，但也有可能发生。
当前回答
问:所以我的问题是——如果 从析构函数抛出会导致 未定义的行为，你该如何处理 在析构函数期间发生的错误?
A:有几种选择:
让异常流出析构函数，而不管其他地方发生了什么。在这样做的时候，要意识到(甚至害怕)std::terminate可能会随之而来。 永远不要让异常从析构函数流出。可能是写一个日志，一些大红色坏文本，如果可以的话。 我的最爱:如果std::uncaught_exception返回false，让你的异常流出。如果返回true，则退回到日志记录方法。
但加进d'tors好吗?
我同意上面的大部分观点，在析构函数中最好避免抛出，因为它可以在析构函数中抛出。但有时你最好接受它的发生，并妥善处理。我选择上面的3。
在一些奇怪的情况下，从析构函数抛出实际上是个好主意。 比如“必须检查”错误代码。这是一个从函数返回的值类型。如果调用者读取/检查包含的错误代码，返回值将静默销毁。 但是，如果返回值超出作用域时还没有读取返回的错误代码，则它将从析构函数抛出一些异常。
其他回答
c++的ISO草案(ISO/IEC JTC 1/SC 22 N 4411)
因此，析构函数通常应该捕获异常，而不是让它们从析构函数传播出去。
为在try块到throw-的路径上构造的自动对象调用析构函数的过程 表达式称为“堆栈unwind”。[注意:如果在堆栈展开期间调用析构函数退出 异常，std::terminate被调用(15.5.1)。因此，析构函数通常应该捕获异常，而不是let 它们从析构函数中传播出去。-结束注]
从析构函数抛出异常永远不会导致未定义的行为。
The problem of throwing exceptions out a destructor is that destructors of successfully created objects which scopes are leaving while handling an uncaught exception (it is after an exception object is created and until completion of a handler of the exception activation), are called by exception handling mechanism; and, If such additional exception from the destructor called while processing the uncaught exception interrupts handling the uncaught exception, it will cause calling std::terminate (the other case when std::exception is called is that an exception is not handled by any handler but this is as for any other function, regardless of whether or not it was a destructor).
如果正在处理未捕获的异常，您的代码永远不知道附加的异常是否会被捕获，或者是否会归档未捕获的异常处理机制，因此永远不知道抛出异常是否安全。
但是，有可能知道正在处理未捕获的异常(https://en.cppreference.com/w/cpp/error/uncaught_exception)，因此可以通过检查条件来过度处理，只在情况不是这样的情况下抛出(在某些情况下它不会抛出，但它是安全的)。
但在实践中，将程序分成两种可能的行为并没有什么用——它只是无助于你设计出一个设计良好的程序。
If you throw out of destructors ignoring whether or not an uncaught exception handling is in progress, in order to avoid possible calling std::terminate, you must guarantee that all exceptions thrown during lifetime of an object that may throw an exception from their destructor are caught before beginning of destruction of the object. It is quite limited usage; you hardly can use all classes which would be reasonably allowed to throw out of their destructor in this way; and a combination of allowing such exceptions only for some classes with such restricted usage of these classes impede making a well-designed program, too.
你的析构函数可能在其他析构函数链中执行。抛出未被立即调用者捕获的异常可能会使多个对象处于不一致的状态，从而导致更多的问题，而不是在清理操作中忽略错误。
在这里，我们必须有所区分，而不是盲目地按照具体情况的一般建议行事。
请注意，下面的内容忽略了对象容器的问题，以及在容器内存在多个对象的d' ator时该怎么办。(它可以被部分忽略，因为有些对象就是不适合放入容器中。)
当我们把类分成两种类型时，整个问题就更容易思考了。类医生可以有两个不同的职责:
(R)释放语义(也就是释放内存) (C)提交语义(即将文件刷新到磁盘)
如果我们以这种方式看待这个问题，那么我认为(R)语义永远不应该引起来自dtor的异常，因为a)我们对此无能为力，b)许多自由资源操作甚至不提供错误检查，例如void free(void* p);。
具有(C)语义的对象，例如需要成功刷新其数据的文件对象或在dtor中执行提交的(“范围保护”)数据库连接是另一种类型:我们可以对错误(在应用程序级别)做一些事情，并且我们真的不应该继续，就像什么都没有发生一样。
如果我们遵循RAII路线，并允许在d'tors中具有(C)语义的对象，我认为我们还必须允许这种d'tors可以抛出的奇数情况。因此，您不应该将此类对象放入容器中，并且如果committor在另一个异常活动时抛出，则程序仍然可以terminate()。
关于错误处理(提交/回滚语义)和异常，Andrei Alexandrescu有一个很好的演讲:c++ /声明性控制流中的错误处理(在NDC 2014举行)
在细节中，他解释了Folly库如何为他们的ScopeGuard工具实现UncaughtExceptionCounter。
(我应该指出，其他人也有类似的想法。)
虽然这次演讲的重点不是从一个d'tor投掷，但它展示了一个今天可以用来解决何时从d'tor投掷问题的工具。
在未来，可能会有一个std特性，请参阅N3614，并对此进行讨论。
Upd '17: c++ 17的std特性是std::uncaught_exceptions afaikt。我将快速引用cppref的文章:
笔记 使用int返回uncaught_exceptions的示例是... ...第一个 创建一个保护对象并记录未捕获异常的数量 在它的构造函数中。输出是由守卫对象执行的 析构函数，除非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.
