[轉(zhuǎn)]http://m.shnenglu.com/tiandejian/archive/2007/04/22/ecpp_08.html
第8條： 防止因異常而中止析構(gòu)函數(shù)
C++ 并 沒(méi)有禁止析構(gòu)函數(shù)引發(fā)異常，但 是 C++ 十 分不推薦這一做法。這樣做有充足的理由。請(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)生無(wú)法預(yù)知的行為。本示例將產(chǎn)生無(wú)法預(yù)知的行為。在使用其它的標(biāo)準(zhǔn)庫(kù)容器（比 如 list 、 set 等），任意的 TR1 容 器（參見(jiàn) 第 54 條 ），甚至是一個(gè)數(shù)組，同樣都會(huì)產(chǎn)生無(wú)法預(yù)知的行為。然而為你帶來(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ù)的某一操作可能失敗，并且有可能對(duì)這一失敗的操作拋出一個(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;
};
客戶端程序員可以這樣編寫：
{ // 開(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ú)法運(yùn)行下去了，上面的方法就是一個(gè)可行的選擇。如果允許析構(gòu)函數(shù)傳播異常將導(dǎo)致程序行為無(wú)法預(yù)知，這樣做的優(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ù)再次嘗試。這可以防止已建立的連接發(fā)生泄漏。然而，如果在 DBConn 的析構(gòu)函數(shù) [1] 中對(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)閉連接，
db.close(); // 則在這里關(guān)閉它
}
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)單易用”這一忠告（見(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ú)法避免不成熟的終止和未知行為。在上邊的示例中，讓客戶端程序員自己手動(dòng)調(diào)用 close 并不會(huì)為其帶來(lái)過(guò)多的負(fù)擔(dān)，相反地，這樣做為客戶端程序員提供了處理錯(cuò)誤的機(jī)會(huì)，否則他們就會(huì)束手無(wú)策。如果他們沒(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ò)誤，是他們自己選擇不去利用它的。
需要記住的
l 永遠(yuǎn)不要讓析構(gòu)函數(shù)引發(fā)異常。如果析構(gòu)函數(shù)所調(diào)用的函數(shù)會(huì)拋出異常的話，那么析構(gòu)函數(shù)中要捕捉到所有異常，然后忽略它們或者終止程序。
l 在一次操作中，如果一個(gè)類的使用者有能力對(duì)拋出異常作出反應(yīng)，那么這個(gè)類應(yīng)該提供一個(gè)常規(guī)的函數(shù)（而不是析構(gòu)函數(shù)）來(lái)進(jìn)行這一操作。
[1] 原文有 誤（ DBConnection 的析構(gòu)函數(shù)），此處始終未涉及到 DBConnection 的析 構(gòu)函數(shù)。——譯注