C 異常處理程式設計的三個境界

這是上一次看完herb sutter的《exceptional c++》後形成的看法，因為懶於更新blog，一直沒有寫下來。

一般講到三個境界，很多人會聯想到……#1見山是山，見水是水#2見山不是山，見水不是水#3見山還是山，見水還是水。嗯沒錯，區區這裡說的也是這東西，只不過是有關程式設計，有關c++，有關異常而已。

事情源起於今天下班時間過後，老大隨著他的手機鈴聲《上海灘》瀟灑地下班了。留下區區和梁兄在辦公室裡，當時他好像在對乙個rdi程式進行逆向工程，而區區只是在擺弄oberon。

「你覺得用c++進行異常安全性程式設計時最重要的正規化是什麼？try,catch,finally要怎麼使用才得當？」梁忽然地就問了。

老實說，牛x得不得了的梁很少跟在下請教問題的（雖然這個問句有強烈的討論意味，但是區區就權當是在被「請教」了），所以覺得應該盡可能答得好一些。

「編寫異常安全的c++程式，最好就是，不要使用try,catch,finally。」——區區這樣回答的。

「哦，很怪喔，那怎麼能怎麼處理呢？」————就知道會被追問~~

於是，那區區就說：

是這樣的，有關異常的c++程式設計，有三個境界：

#第乙個境界就是：程式中看到不try,catch,finally。

這是新手的水平，他不知道有的模組/函式是會有異常丟擲的，不處理的話，程式會當掉，很多資源會不能及時正確**。或者他寫程式時反覆應用errno或者檢查返回值的方式來處理異常情況，排錯**和正常流程**攪在一起，混亂不堪。

#第二個境界就是：程式中看到好多好多try,catch,finally。

這是入門級的水平，他懂得利用拋異常的方式來處理錯誤情況，所以在程式中，正常的流程會統一在try裡，各種錯誤處理，都安排在catch當中，小心翼翼地做好的善後工作。有時候狠起來還使用catch(...)來強行把所有的異常都壓下來。這樣沒有什麼混亂？才怪，各種善後處理雖然都做了，但是他不知道要寫多少個try，多少個catch，而且經常要把思路放到catch當中去。

#第三個境界就是：程式中還是看到不try,catch,finally。

然而有不同，這一回他是手中無劍心有劍的高手境界了。

他知道異常安全的三個保證，並且懂得在什麼時候分別提供#資源**保證#資料一致性保證#無異常保證。

---他會使用c++超強的raii(資源獲取即初始化)來使得資源在產生異常時會自動**（寫乙個類就可以管理一種資源，一勞永逸，不用天天catch來catch去）。

---他會使用pimpl技法（我比較喜歡叫它疙瘩技法）幫助實現raii，並把邏輯操作分派到各個成員內部當中，使之在發生異常時保持一致性。

---他另外還會常常使用乙個no throw的swap操作一次性把所有的操作完成。這樣的話，物件就不會成為爛尾樓。

於是，這個高手寫的類自己不用異常來打擾你，如果真的在內部其它類發生了異常，這個異常也安全地透過這個高手的類傳到更上一層去，不破壞類本身的資料完整性。雖然異常還會有，但是，安全了~

所以綜合來說，要寫好乙個異常安全的模組，最好有幾個東東要牢記於心~：：

異常（它會出現），raii，pimpl，資料一致性，swap。

如果忘了，可以翻出boost::shared_ptr的源程式好好看一遍。（這句話其實沒敢跟師兄說）

其實少用try catch，是對於乙個相對的說法。當知道乙個模組要通過拋異常來報告錯誤，並且這個錯誤的處理責任是模組呼叫者時，就應當使用try，別把異常給漏了。比如說boost::lexical_cast的使用者~

再比如梁的模組一般最終要以c函式介面形式發布，那在模組的最上層，加乙個try，也是合適的。

而且梁自己也說了，現在正在逆向的這個程式，使用了很好的seh（這是windows的異常處理功能），所以很容易把握開發者的意圖————你看，用異常處理來寫程式就是好，連反彙編的可讀性都比返回錯誤碼的正規化要強得多（當然，有的人不希望被逆向的）。

C 異常處理程式設計的三個境界

C 異常處理程式設計的三個境界

人生三個境界

讀史的三個境界

C 異常處理程式設計的三個境界

C 異常處理程式設計的三個境界

人生三個境界

讀史的三個境界

相關推薦