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