C++并沒有禁止析構函數引發異常，但是C++無疑不會推薦這一做法。這樣做有充足的理由。請看下邊的代碼：
class Widget {
public:
...
~Widget() { ... } // 假設它會引發一個異常
};
void doSomething()
{
std::vector<Widget> v;
...
} // v在這里被自動銷毀
當vector v被銷毀時，它也有責任銷毀其所包含的所有的Widget。假設v中包含十個Widget，并且在對第一個進行析構時拋出了一個異常。那么剩下的九個Widget則仍需要得到銷毀（否則它們所占有的資源就會發生泄漏），所以v應該為所有剩下的Widget——調用析構函數。但是假設在對這些對象進行銷毀時，又出現了第二個Widget拋出了一個異常，現在同時存在著兩個活動的異常，這對于C++來說已經是太多了。在極端巧合的情形下，程序中同時出現了兩個活動的異常，此時程序的運行要么會中止，要么會產生未定義行為。本示例將產生未定義行為。在使用其它的標準庫容器（比如list、set等），任意的TR1容器（參見條目54），甚至是一個數組，同樣都會產生未定義行為。然而為你帶來麻煩的不僅僅是這些容器或者數組，析構函數拋出異常會引發不成熟的程序終止或者未定義行為，甚至在沒有容器和數組的情況下也會發生。C++不喜歡能夠引發異常的析構函數！
這個問題很好理解，但是當你的析構函數的某一操作可能失敗，并且有可能拋出一個異常時，你應該怎么做呢？請看下邊的示例，其中假設你使用一個類進行數據庫連接：
class DBConnection {
public:
...
static DBConnection create(); // 返回DBConnection對象的函數；
// 為簡化代碼省略了參數表
void close(); // 關閉連接；若關閉失敗則拋出異常
};
為了確保客戶不會忘記為DBConnection對象調用close函數，一個可行的方案是：創建一個新的類來管理DBConnection的資源，在這個類的析構函數中調用close。這種資源管理類在第三章中作詳細的介紹，在本節中，我們僅關心這些類的析構函數是什么樣的：
class DBConn { // 該類用來管理 DBConnection對象的資源
public:
...
~DBConn() // 確保數據庫連接總能關閉
{
db.close();
}
private:
DBConnection db;
};
客戶可以這樣編寫：
{ // 開始一個程序塊
DBConn dbc(DBConnection::create());
// 創建一個 DBConnection對象，然后
// 把它交給一個 DBConn對象來管理
... // 通過DBConn的接口使用這個
// DBConnection對象
} // 在該程序塊的最后，這個DBConn對象
// 被銷毀了，就好像自動調用了那個
// DBConnection對象的close函數
只要對close的調用能成功，這個DBConn的方案就是一個好主意，但是一旦這一調用會引發一個異常， DBConn的析構函數則會使這個異常蔓延開來，也就是所謂的，允許“因異常而中止析構函數”。這便是問題所在，因為析構函數在此處拋出異常意味著麻煩將會出現。
避免這類麻煩有兩種主要的辦法。DBConn的析構函數可以：
l 終止程序——如果close拋出異常則終止程序，通常通過調用abort實現：
DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
在日志上記載：調用close失敗;
std::abort();
}
}
如果在析構過程中發生了一個錯誤，從而程序無法繼續運行，上面的方法就是一個可行的選擇。如果允許析構函數傳播異常將導致程序產生未定義行為，這樣做的優勢就在于可以避免類似的事情發生。也就是說，調用abort函數可以防止程序產生未定義行為。
l 忽略這個異常——由調用close函數產生的異常
DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
在日志上記載：調用close失敗;
}
}
在大多數情況下，忽略掉異常的存在并不是一個好主意，因為這樣做你會錯過一些重要的信息——一些東西出錯了！然而在某些時刻，忽略異常比讓程序擔上不成熟終止或未定義行為的風險要強一些。為了讓忽略異常成為一個可行的方案，程序必須有能力在忽略剛發生的錯誤之后仍然可以穩定地繼續運行。
這兩個方案都不是那么的動人心弦。它們存在著同樣的問題，即二者都沒有辦法在第一時間對close拋出的異常作出反應。
一個更好的策略是：改進DBConn接口的設計，使得客戶有機會自己處理可能發生的問題。舉例說，DBConn可以自己提供一個close函數，這樣就為客戶提供了途徑來處理由DBConnection的close產生的異常。這樣做還可以跟蹤DBConnection所建立的連接是否被DBConnection自己的close函數正常關閉，如果關閉失敗則在DBConn的析構函數將其關閉。這可以防止已建立的連接發生泄漏。然而，如果在DBConn的析構函數中對close的調用仍然不成功，我們還是需要中止運行或者忽略異常。
class DBConn {
public:
...
void close() // 新函數，供客戶調用
{
db.close();
closed = true;
}
~DBConn()
{
if (!closed) {
try { // 如果客戶沒有關閉連接，則在這里關閉它
db.close();
}
catch (...) { // 如果沒有正常關閉，首先作好記錄，
在日志上記載：調用close失敗; // 然后終止或忽略
...
}
}
private:
DBConnection db;
bool closed;
};
調用close的責任原本是DBConn的析構函數的，而現在我們卻將其轉交給DBConn的客戶（DBConn的析構函數還包含一個“備用的”調用）。可能你會認為這樣做實屬毫無顧忌地推卸責任，你甚至可能認為這是對“讓接口更易于正確用”這一忠告（見條目18）的違背。實際上，兩者都不是。如果一個操作可能由于一次異常的拋出而失敗，同時這個異常有必要得到處理，這一異常不應該來自析構函數。這是因為引發異常的析構函數是十分危險的，它使你的程序始終位于風口浪尖：你無法避免不成熟的終止和未定義行為的風險。在上邊的示例中，讓客戶自己手動調用close并不會為其帶來過多的負擔，相反地，這樣做為客戶提供了處理那些原本他們無法接觸的錯誤的機會。如果他們沒有發現這個機會的裨益所在（可能是因為他們相信錯誤不會發生得這么巧），他們可以忽略這個機會，然后依賴DBConn的析構函數為他們調用close函數。如果就在這一刻發生了錯誤——也就是說close確實拋出了異常——DBConn會忽略這個異常或者終止程序。客戶對此也沒有什么好抱怨的，畢竟，在處理問題時是他們犯下了第一個錯誤，是他們自己選擇不去利用它的。
時刻牢記
l 永遠不要讓析構函數引發異常。如果析構函數所調用的函數會拋出異常的話，那么析構函數中要捕捉到所有異常，然后忽略它們或者終止程序。
l 在一次操作中，如果類的客戶有必要對拋出的異常做出反應，那么這個類應該提供一個常規的函數（而不是析構函數）來進行這一操作。