在我的析构函数中，我必须清理一些资源。假设我有三个电话来清除可能抛出的资源。既然让异常离开析构函数是不好的，那么我的设计模式应该是什么？显然下面的方式是不可扩展的。
谢谢。
class B::~B(){
try{
clearResourceA()
}
catch{
try{
clearResourceB();
}
catch{
clearResourceC();
}
clearResourceC();
}
clearResourceB();
.
.
}
【问题讨论】：
标签： c++
为什么不：
try{clearResourceA();} catch(...){}
try{clearResourceB();} catch(...){}
try{clearResourceC();} catch(...){}
【讨论】：
将每个资源封装在一个类中，并在其析构函数中清除它们（使用周围的 try/catch）：
struct ProperlyManagedA {
// some means of using the resource - a rudimentary way is this:
A &getA() { return a; }
const A &getA() const { return a; }
// cleanup
~ProperlyManagedA() {
try {
a.clear(); // whatever it is ClearResourceA actually does
} catch (...) {}
}
private:
A a;
}
带有自定义删除器的shared_ptr 是实现此目的的一种方法，无需为每种类型的资源创建整个类。
您可能会改进丢弃异常（例如记录问题），具体取决于抛出的内容。
更好的是，修改资源 A、B 和 C，以便它们在自己的析构函数中清除自己。不过，这可能是不可能的。
无论哪种方式，您都可以将任意数量的此类资源放入一个类中，而无需向该类的析构函数添加任何代码。这就是“可扩展性”。 RAII 的全部意义在于，资源的每个用户不应该为了正确使用资源而编写清理代码。
【讨论】：
使用 catch-all（即 catch (...)）捕获任何可以在析构函数中抛出的东西，并尽最大努力处理抛出的异常。确保没有异常从析构函数中传播出去，这将帮助您防止这种情况发生。
【讨论】：
您还可以包装您的 ClearResources 函数以确保它们永远不会抛出。为什么他们还是会扔？
【讨论】：
因为您询问了设计模式，所以我将告诉您我成功使用的经验法则。 所有具有清理/终止功能的函数都应该绝不抛出。
这些函数通常是公认的名称：
这背后的基本原理是：
我可以尝试使用RAII pattern。但即使在这种情况下，上述规则也会被使用。
【讨论】：
try
{
ClearResourceA();
}
catch(...)
{
ExceptionWasThrown();
}
try
{
ClearResourceB();
}
catch(...)
{
ExceptionWasThrown();
}
...
【讨论】：