Shuffy

第29條：     力求使代碼做到“異常安全”

異常安全看上去像是孕育生命，但是請您先把這種觀點暫時放在腦后。因為在一對戀人結婚之前，討論生育問題還為時尚早。

假設我們正在設計一個表示 GUI 菜單的類，這種菜單是有背景圖片的，這個類用于多線程環境中，所以它擁有一個互斥鎖來確保正常的并發控制：

下面是 PrettyMenu 的 changeBackground 函數實現的一個備選方案：

從異常安全的角度來說，這個函數簡直一無是處。異常安全的兩個基本要求，這個函數完全沒有考慮到。

當拋出異常時，異常安全的代碼應該做到：

l 不 要泄漏資源。 上面的代碼沒有進行這項檢測，這是因為如果 “ new Image(imgSrc) ” 語句產生了異常 ，那么對 unlock 的調用則永遠不會兌現，這樣互斥鎖將永遠不會被解開。

l 不能讓數據結構遭到破壞。 如果“ new Image(imgSrc) ”拋出異常， bgImage 就會指向一個已經銷毀的對象。另外，無論新的圖形是否裝載成功， imageChanges 的數值都會增加。（從另一個角度說，舊的圖形肯定是被刪除了，那么你又怎么能確保圖形被“改變”了呢。）

處理資源泄漏問題還是比較簡單的，因為第 13 條中介紹過如何使用對象來管理資源，第 14 條中介紹過如何通過 Lock 類確保互斥鎖在適當的時候被解開：

能夠讓函數變得更短，是諸如 Lock 這樣的資源管理類最讓人興奮的事情之一。你是否注意到：這里甚至不需要調用 unlock 。更短的代碼就是更優秀的代碼，因為代碼越短，它帶來錯誤和誤解的機會就越少。這是一條通用的準則。

把資源泄漏問題放在一旁，讓我們把注意力集中在數據結構破壞的問題上。這里我們可以進行一次選擇，但是在進行選擇之前，我們首先要了解所需要的幾個術語。

異常安全函數做出的保證可以總結為三個層面：

l 提供基本保證的函數會做出這樣的承諾：如果拋出了一個異常，那么程序中的一切都將保持合法的狀態。沒有任何對象或數據結構會遭到破壞，所有的對象的內部都保持協調的狀態（比如說所有類不變式都得到滿足）。然而，程序的具體狀態可能是無法預知的。比如說，我們可以這樣編 寫 changeBackground ：如果某一時刻拋出一個異常，那么 PrettyMenu 對象可能繼續使用舊的背景圖片，也可以用某個默認的背景圖片來代替。但是客戶端程序員無法做出任何預測。（為了找到答案，客戶端程序員大概會調用某個能告訴他們當前背景圖片是什么的成員函數。）

l 提供增強保證的函數會做出這樣的承諾：如果拋出了一個異常，那么函數的狀態將保持不變。這樣的函數看上去與原子有些相像，因為如果調用成功了，它就會大獲全勝；一旦出了差錯，那么就會一敗涂地，程序狀態將顯示它從來沒有被調用過。

使用提供強保證的的函數要比使用僅提供基本保證的函數簡單一些，這是因為在調用一個提供強保證的函數之后，程序只可能存在兩種狀態：一、按預期進行，函數成功執行；二、程序將保持函數調用前的狀態。反觀提供基本保證的函數，如果在調用它時拋出了一個異常，那么程序可能會處于任何合法的狀態。

l 提供零異常保證的函數承諾程序決不會拋出異常，因為它們永遠都會按部就班的運行。所有的內建數據類型 （ int 、指針，等等）的操作都是零異常的（提供零異常保證）。這是異常安全代碼必不可少的一個因素。

我們可以假設包含空異常規范 [1] 的函數為零異常的，這樣做看上去是合理的，但是事實并不一定是這樣的，請看下面的函數：

這并不是說 doSomething 將永遠不會拋出異常，這只是說，如果 doSomething 拋出了異常，那么此時就出現了一個嚴重的錯誤，同時程序應該調用一個名為 unexpected 的函數 [2] 。實際上， doSomething 可能根本不會提供任何異常保證。函數的聲明（包括它的異常規范，如果有的話）并不會告訴你它是否正確、是否小巧、是否高效，同時也不會告訴你它他提供了哪個層面上的異常安全保證。所有那些特性都要在函數實現中確定下來，而不是聲明中。

異常安全的代碼必須要提供上述三個層面的保證中的一種。否則它就不是異常安全的。那么你要做的就是：對于所寫的每一個函數都要確定使用哪一層面保證。除非我們正在處理沒有做到異常安全的糟糕代碼（這一點我們稍候再提）。只有當你的“優秀”的需求分析小組提出：你的程序需要泄露資源，并且需要使用破壞的數據結構時，不提供任何異常安全保證也許才是一個可行的選擇。

作為一個通用的準則，你會希望提供可行范圍內最強化的保證。從異常安全的角度來說，零異常的函數是美妙的，但是如果不去調用拋出異常的函數，你是很難逾越 C++ 中 C 這一部分的。只要涉及動態內存分配（比如所有的 STL 容器），如果無法尋找到足夠的內存來滿足當前的要求，那么通常程序都會拋出一 個 bad_alloc 異常（參見第 49 條）。在可行的時候你應該為函數提供零異常保證，但是對于大多數函數而言，懸在是介于基本保證和增強保證之間的。

對于 changeBackground 而言，或多或少地提供增強保證并不是件難事。首先，我們可以改變 PrettyMenu 的 bgImage 數據成員的類型，從一個內建的 Image* 指針類型轉變為智能資源管理指針（參見第 13 條）。坦白的說，單獨從防止資源泄漏理論的角度上說，這是一個非常好的設計方案。事實上它簡單地通過使用對象（比如智能指針）來管理資源（也就是遵循了 13 條中的建議，這是優秀設計的基本要求），幫助我們提供了增強的異常安全保證。在下面的代碼中，我將使用 tr1::shared_ptr ，這是因為它的行為更直觀，在進行復制操作時比 auto_ptr 更合適。

其次，我們從新編排了 changeBackground 中語句的順序，從而使 imageChanges 直到圖像改變以后才進行自加。作為一個通用的準則，直到一個事件真真切切地發生了，才去改變對象的狀態來描述這個事件。

下面是改進后的代碼：

請注意這里不需要手動刪除舊圖片，因為這件事情完全由智能指針代勞了。而且，只有在新圖像成功創建之后，刪除操作才有意義。更精確地說， tr1::shared_ptr::reset 函數只有在其參數（ ”new Image(imgSrc)” 的結果）成功創建以后才會得到調用。由于只有在調用 reset 過程中才會使用 delete ，因此如果從未進入該函數，就永遠不會用到 delete 。注意：使用對象（ tr1::shared_ptr ）來管理資源（動態分配的 Image ），再次精簡了 changeBackground 。

如前所述，這兩項改變或多或少地使 changeBackground 滿足了增強的異常安全保證。可是 白璧微瑕， imgSrc 參數 還有 一個小問題。 如果 Image 的構造函數拋出了一個異常，那么輸入流的讀標記很可能會被移動，這樣的移動可能會造成狀態的變化，而這種變化對程序其它部分來說是可見的。在 changeBackground 指明這一問題之前，它僅僅提供基本的異常安全保證。

然而，讓我們把這個問題暫時放在一旁，假裝 changeBackground 確實可以提供增強保證。（我相信你可以想出一個辦法來，可以通過改變參數的類型：從輸入流變為包含圖像信息的文件名。）有一個一般化的設計方案，可以使函數做到增強保證，了解這種放案十分重要。這一方案一般稱為“復制并交換。”從理論上來講，它非常簡單。為需要修改的對象做一個副本，然后將所有需要的改變應用于這個副本之上。如果期間任一個修改操作拋出了異常，那么原始的對象依然紋絲未動。在所有改變順利完成之后，通過一次不拋出異常的操作將修改過的對象與原始對象相交換即可。

上述方案通常這樣實現：將對象的所有數據從“真實的”對象復制到一個獨立實現的對象中，然后為真實對象創建一個指針，將其指向這個實現對象。這通常稱為“ pimpl idiom ”（指向實現的指針），第 31 條中將將解它的一些細節。對于 PrettyMenu 而言，典型的實現是這樣的：

在這個示例中，我做出了這樣的選擇： PMImpl 是一個結構體而不是類，這是因為 PrettyMenu 數據的封裝性是通過 pImpl 確定為私有的。將 PMImpl 實現為類不但不會帶來便利，而且效果也不好。（它同樣使面向對象的偏執狂陷入絕境。）如果需要，可以把 PMImpl 放置在 PrettyMenu 的內部，但是打包問題與編寫異常安全代碼的問題似乎沒有什么聯系，這不是我們當前所關注的。

有些對象狀態修改的操作，要求要么是完全修改，要么完全不變，此時復制并交換策略是完美的。但是，一般情況下，它并不能確保整個函數都做到增強保證。請看下面 changeBackground 的一個抽象—— someFunc ，它使用了復制并交換策略，但是它包含了 2 個其它函數的調用：

這里應該很清楚了：如 果 f1 或者 f2 沒有達到增強保證的要求，那么 someFunc 就很難滿足增強保證。比如，假設 f1 僅提供了基本保證，為了讓 someFunc 能滿足增強保證，就必須要為其編寫額外的代碼，用于調用 f1 之前確定整個程序的狀態，捕獲 f1 拋出的所有異常，然后恢復原始的狀態。

如果 f1 和 f2 都滿足了增強保證，那么事情也不會好到哪去。如果 f1 運行完成，那么程序的狀態可能經歷了任意的修改過程，因此，如果 f2 在此時拋出了一個異常，那么程序的狀態就可能會與 someFunc 被調用時不一致，即使 f2 沒有做任何修改操作。

這個問題是個側面效應。只要函數操作僅僅針對本地的狀態（比如說， someFunc 僅僅影響到它所調用對象的狀態），提供增強保證就相對簡單些。當函數對于非本地數據存在這一側面效應時，則更加困難些。比如說，如果調用 f1 引入的側面效應是數據庫被修改了，那么讓 someFunc 滿足異常安全的增強保證就比較困難。一般來說，已經被系統接受的數據庫修改很難恢復，這是因為其它的數據庫用戶已經看到了數據庫的新狀態。

不管你情愿與否，諸如這樣的問題會為你在編寫增強保證的函數時設置重重障礙。另一個問題是：效率。復制并交換策略的核心思想就是修改對象副本的數據，然后通過一個不會拋出異常地操作交換修改后的數據。這需要為每個需要修改的對象創建出一個副本，這樣做顯然會浪費時間和空間，你也許不會情愿使用這一策略，現實條件有時也會阻止你。增強保證是我們良好的預期目標，只要可行你就應該提供，但是現實中它并不總是可行的。

在增強保證不可行時，你應該提供基本保證。從實用角度說，如果你發現你可以為某些函數提供增強保證，但是由此帶來的效率和復雜度問題使得增強保證變得得不償失。只要你在必要的時候做出了努力使適當的函數滿足了增強保證，那么對于一些函數僅提供基本保證就是無可厚非的。對于大多數函數而言，基本保證已經是合理的、完美的選擇了。

如果你正在編寫一個完全不提供異常安全保證的函數，那么就是另一番景象了。因為在這里完全可以在未證明你無罪之前假定你有罪。你本應該編寫異常安全代碼。但是你也可以為自己做出強有力的辯解。請再次考慮一下 someFunc 的實現，它調用了兩個函數： f1 和 f2 ，假設 f2 完全沒有提供異常安全保證，即使基本保證也沒有，這就意味著一旦 f2 拋出一個異常，程序可能會在 f2 的內部發生資源泄露。這意味著 f2 中可能會有破損的數據結構，比如：排好序的數組可能不再按順序排列，在兩個數據結構之間轉送的對象也可能會丟失數據，等等。這樣 someFunc 也無力回天。如果 someFunc 函數調用了沒有提供異常安全保證的函數，那么 someFunc 自身就無法做出任何保證。

讓我們回到本節開篇時所說的“孕育生命”的問題。一位女性要么就是懷孕，要么就是沒有，絕沒有“部分懷孕”的狀態。類似的，一個軟件系統要么是異常安全的，要么就不是。沒有所謂的“部分異常安全”的狀態存在。在一個系統中，即使只有一個單獨的函數不是異常安全的，那么整個系統也就不是異常安全的。遺憾的是，許多較為古老的 C++ 代碼在編寫的時候完全沒有考慮到異常安全問題，因此當今許多系統便不是異常安全的。新系統中混雜著異常不安全的編寫習慣。

沒有理由去維持現狀。當編寫新代碼或者修改現有代碼的時候，要認真考慮一下如何使之做到異常安全。首先，使用對象管理資源。（依然參見第 13 條。）這將有效地防止資源泄露。然后對于你要編寫的每個函數確定你要使用哪一層面的異常安全保證，只有在調用古老的、沒有異常安全保證的代碼時才放棄異常安全保證，因為你別無選擇。記錄下你的選擇，這即是為了你的客戶端程序員，也是為了今后的維護人員。函數的異常安全保證位于接口的可見部分，因此你應該認真規劃它，就像你認真規劃接口其它部分一樣。

四十年前，人們迷信充斥著 goto 的代碼是完美的，現在我們卻為了編寫結構化控制流而努力。二十年前，全局的完全可訪問的數據也是高踞神壇，然而當今我們卻在提倡封裝數據。十年前，編寫函數時不去考慮異常的影響的做法倍受追捧，但是今天，我們堅定不渝的編寫異常安全代碼。

歲月荏苒，我們在學習中不斷進步……

銘記在心

l 異常安全的函數即使在異常拋出時，也不會帶來資源泄露，同時也不允許數據結構遭到破壞。這類函數提供基本的、增強的、零異常的三個層面的異常安全保證。

l 增強保證可以通過復制并交換策略來實現，但是增強保證并不是對所有函數都適用。

l 函數所提供的異常安全保證通常不要強于其調用的函數中保證層次最弱的一個。