析构函数引发异常的问题
-
异常同时存在的隐患：C++ 虽未禁止在析构函数中引发异常，但坚决阻止这样做。以
std::vector等容器包含对象为例，当容器析构时要析构其中元素，若在析构元素（如Widget类对象）过程中连续抛出异常，出现两个或多个活动异常时，程序可能会终止或者出现未定义行为，使用其他标准库容器、TR1 中的容器甚至数组等情况都可能引发同样问题，即便不涉及容器和数组，析构函数引发异常也可能导致程序过早终止或出现未定义行为。 -
资源管理类示例中的问题：以
DBConnection类及管理它的DBConn类为例，若DBConn类析构函数调用DBConnection类的close方法（假设close可能抛出异常），当异常抛出后，析构函数传播该异常会带来麻烦，因为这相当于把棘手问题抛出去了，不符合析构函数的特性。
避免析构函数引发异常麻烦的常见方法及问题
- 终止程序：像在
DBConn析构函数中通过try-catch捕获异常，若捕获到异常则记录日志后调用abort终止程序。这种做法适用于析构过程遭遇错误后程序无法继续运行的情况，好处是能防止因析构函数传播异常导致的未定义行为。 - 抑制异常：同样在
DBConn析构函数的try-catch中，捕获异常后只记录日志，不向外传播异常。不过通常抑制异常不是好主意，因为会隐瞒操作失败的重要信息，但在某些程序能在忽略错误后继续可靠运行的场景下，这比冒程序过早终止或出现未定义行为的风险更可取。这两种方法的共同问题是程序无法对引起close抛出异常的条件做出有效回应。
更好的策略及相关理念
- 改进接口设计：设计
DBConn类的接口，让客户有机会对可能出现的问题做出回应。比如提供close函数给客户去调用处理异常，同时类内部跟踪连接是否已关闭，若客户未关闭则在析构函数中进行 “候补” 关闭操作。这样能防止连接泄漏，若析构函数中关闭操作失败，还可再采取终止程序或抑制异常的做法。 - 核心原则：析构函数应该永不引发异常。若析构函数调用可能抛出异常的函数，需捕捉所有异常并抑制它们或者终止程序；如果类的客户需要对某个操作抛出的异常做出回应，该类应提供常规的非析构函数来完成此操作，因为析构函数引发异常有导致程序过早终止或出现未定义行为的风险，让客户通过非析构函数处理异常是给他们应对错误的机会。