[轉]http://www.shnenglu.com/tiandejian/archive/2007/04/22/ecpp_08.html
第8條： 防止因異常而中止析構函數
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 的析構函數 [1] 中對 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 在一次操作中，如果一個類的使用者有能力對拋出異常作出反應，那么這個類應該提供一個常規的函數（而不是析構函數）來進行這一操作。
[1] 原文有 誤（ DBConnection 的析構函數），此處始終未涉及到 DBConnection 的析 構函數。——譯注