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