#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()并处理任何异常。另一方面，如果它们不关心，那么析构函数将被留下来处理这种情况。

Scott Myers在他的书《Effective c++ "Effective c++ "》中有一篇关于这个主题的优秀文章;

编辑:

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

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

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

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

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

你要问的是在这种情况下

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

什么应该捕获异常?foo的调用者应该这样做吗?或者应该由foo来处理它?为什么foo的调用者要关心foo内部的某个对象?可能有一种语言定义的方式是有意义的，但它将是不可读的和难以理解的。

更重要的是，对象的内存去哪里了?对象拥有的内存到哪里去了?它仍然被分配吗(表面上是因为析构函数失败了)?再考虑对象在栈空间中，所以显然不管它去了。

然后考虑这个例子

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的指针没有了，你就有点SOL了，你有内存泄漏。

下面是一种安全的做法

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


};

也可以看到这个常见问题解答

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

例如:

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

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

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

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

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

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

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

我目前遵循的策略(很多人都这么说)是，类不应该主动从析构函数抛出异常，而是应该提供一个公共的“关闭”方法来执行可能失败的操作……

.．.但我确实相信容器类型类的析构函数，比如vector，不应该掩盖它们所包含的类抛出的异常。在本例中，我实际上使用了递归调用自身的“free/close”方法。是的，我说的是递归。这种疯狂是有原因的。异常传播依赖于存在一个堆栈:如果发生单个异常，那么一旦例程返回，剩余的析构函数仍将运行，挂起的异常将传播，这很好。如果出现多个异常，那么(取决于编译器)要么第一个异常传播，要么程序终止，这是可以的。如果出现如此多的异常，以至于递归溢出堆栈，那么就有严重的问题，有人会发现它，这也是可以的。就我个人而言，我宁可错误爆发，也不愿隐藏、秘密和阴险。

关键是容器保持中立，由所包含的类决定它们是否从析构函数抛出异常。

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

A:有几种选择:

1. 让异常流出析构函数，而不管其他地方发生了什么。在这样做的时候，要意识到(甚至害怕)std::terminate可能会随之而来。

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

3. my最喜欢的:如果std::uncaught_exception返回false，让你的异常流出。如果返回true，则退回到日志记录方法。

但加进d'tors好吗?

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

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

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

当我们把类分成两种类型时，整个问题就更容易思考了。类医生可以有两个不同的职责:

• (R)释放语义(也就是释放内存)
• (C) 提交语义(也就是冲洗文件到磁盘)

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

具有(C)语义的对象，如需要成功刷新其数据的文件对象或在dtor中执行提交的(“范围保护”)数据库连接是另一种类型:我们可以对错误做了一些事情(在应用程序级别上)，我们真的不应该继续，就像什么都没有发生一样。

如果我们遵循RAII路线，并允许在d'tors中具有(C)语义的对象，我认为我们还必须允许这种d'tors可以抛出的奇数情况。因此，你不应该将这样的对象放入容器中，并且如果提交器在另一个异常活动时抛出，程序仍然可以terminate()。

关于错误处理(提交/回滚语义)和异常，安德烈Alexandrescu有一个很好的讨论: c++中的错误处理/声明性控制流 .(保存在NDC 2014)

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

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

虽然讨论的重点不是从d'tor中抛出，但它展示了一个可以使用今天从d'tor中摆脱何时投球的问题的工具。

在未来中，有五月是对此的std特征，see N3614，和关于它的讨论。

Upd '17: c++ 17的std特性是std::uncaught_exceptions afaikt。我将快速引用cppref的文章:

笔记

使用__abc0 -返回uncaught_exceptions的示例是... ...第一个 创建一个保护对象并记录未捕获异常的数量 在它的构造函数中。输出是由守卫对象执行的 析构函数，除非foo()抛出(，在这种情况下，未捕获的数量 析构函数中的异常大于构造函数中的异常 观察< / p > < / em >)