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

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

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

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

你要问的是在这种情况下

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

};

也可以参考这个FAQ

在这里，我们必须有所区分，而不是盲目地按照具体情况的一般建议行事。

请注意，下面的内容忽略了对象容器的问题，以及在容器内存在多个对象的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()抛出(在这种情况下，未捕获的数量 析构函数中的异常大于构造函数中的异常 观察到)

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

例如:

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

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

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

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

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

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

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

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实际上会被翻译成编译器错误，这将会有很大帮助。这样我们就能在编译时捕获所有这些东西，如果我们实际上无意中编写了一个析构函数，它可能会抛出。

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