原創文章歡迎轉載，但請保留作者信息]
Justin 于 2010-01-03
這里我所說的“對異常免疫的代碼”，原文是exception-safe code。(侯捷的版本是“異常安全代碼”，不過我覺得自己的版本比較容易理解……)
對異常免疫的函數在異常發生的時候應該具備兩個特征：
-
不泄漏任何資源(內存、鎖等等)
-
不造成任何數據結構的損壞
并能夠提供至少以下保證中的一項：
-
基本的保證：當異常拋出時，程序中的對象、數據免遭破壞。
-
較強的保證：當異常拋出時，程序的狀態不會被改變。
從狀態機的角度來看，若成功調用函數，則系統進入成功后的狀態；如果函數中因異常而出錯，系統應該留在調用函數前的狀態：也就是說，系統在調用函數后，只會有兩種狀態。這是比前一條更強的保證。(看來Scott也愛上了比喻：書中說這就好比女生懷孕，要么就是懷上了，要么就是沒中招，沒人能“半”懷孕的@#￥%)
-
最強的保證：不會有異常拋出。例如對內置類型的操作就不會拋出異常。這是最理想的，但也很難做到。更多的函數只能在前兩者中做一選擇。
為了能夠提供較強的保證，也即系統的狀態不因異常拋出與否而變化，大師又重新提出了“先拷貝后交換”(copy-and-swap)這一方法論來。
用不那么嚴謹的說法：為了避免在操作對象時觸發異常影響系統狀態，“先拷貝后交換”先是創建了一個臨時對象，將所有的操作都施加在該臨時對象上。如果沒有出錯，把這個處理過的臨時對象和真正需要處理的對象交換一通，算是順利完成任務；如果有錯并拋出了異常，原系統狀態也不會被影響，因為真正需要處理的對象根本沒有被動過。
當然，天下沒有免費的午餐。
“先拷貝后交換”不僅耗費了一個臨時對象的存儲代價，同時支出的還有后面交換對象時的時間和資源開銷。因此，對異常免疫的較強保證是很好很強大，但是實際中并不是任何時候都需要做到那么高的保證。殺雞豈需用牛刀？
最后要提醒的是，對異常免疫的函數也符合“短板理論”：木桶能裝的水與其最短的那塊木板有關，函數對異常免疫的程度也由函數中程度最低的代碼(包括其調用的函數)決定。某個函數如果調用了另外一個一出現異常就崩潰的函數，那么這個函數就不能提供基本的異常免疫保證。
|