prevent exception from leving destructors.
c++並不禁止析構函式吐出異常,但它不鼓勵這樣做.這是有原因的,考慮以下**:
class widget // 假設這個可能吐出乙個異常
};void dosomething() // v在這裡被自動銷毀
這很容易理解,但如果析構函式必須執行乙個動作,而該動作可能會在失敗時丟擲異常,該怎麼辦?例如,假設使用乙個 class 負責資料庫連線:
class dbconnection ;class dbconn
private:
dbconnection db;
};
// 在區塊結束點,dbconn物件被銷毀,自動呼叫close兩個辦法可以避免這一問題,dbconn的析構函式可以:
1.如果close丟擲異常就程式結束.通常通過呼叫abort完成:
dbconn::~dbconn()
catch ( ... )
}
2.吞下因呼叫close而發生的異常:
dbconn::~dbconn()
catch ( ... )
}
這些辦法都沒有吸引力,問題在於兩者都無法對"導致close丟擲異常"的情況作出反應.
乙個較佳的策略是重新設計dbconn介面,使其客戶有機會對可能出現的問題作出反應.例如dbconn自己可以提供乙個close函式,因而賦予客戶乙個幾乎得以處理"因該操作而發生的異常".dbconn也可以追蹤其所管理的dbconnection是否已被關閉,如果否則由其析構函式關閉.這可防止遺失資料庫連線.然而如果dbconnection析構函式呼叫close失敗,又將回到"強迫結束程式"或"吞下異常"的老路:
class dbconn
~dbcoon() catch ( ... ) }}
private:
dbconnection db;
bool closed;
};
注意:
析構函式絕對不要吐出異常.如果乙個被析構函式呼叫的函式可能丟擲異常,析構函式應該捕捉任何異常,然後吞下它們(不傳播)或結束程式.
如果客戶需要對某個操作函式執行期間丟擲的異常做出反應,那麼 class 應該提供乙個普通函式(而非在析構函式中)執行該操作.
Effective C 條款52 第8章
write placement delete if you write placement new placement new 和 placement delete 並非在c 常見.回憶 條款16和 條款17,當寫乙個如下所示的 new 表示式 widget pw new widget 共有兩個函式...
Effective C 條款15 第3章
provide access to raw resources in resources managing classes 資源管理類 resource managing classes 很棒.它們是對抗資源洩露的堡壘.在乙個良好的環境中將依賴這樣的classes來處理和資源之間的所有互動.而不是直...
Effective C 條款23 第4章
prefer non member non friend functions to member functions 想象有個 class 用來表示網頁瀏覽器,這樣的 class 可能提供眾多函式,如下所示 class webbrowser 許多使用者會想一整個執行所有這些動作,因此webbrows...