第六章 人非圣賢

• 錯誤可能而且必將發生。幾乎任何操作都會帶來意想不到的結果，這種結果與有缺陷的程序中的bug不一樣，因為你預先就知道錯誤會發生。
• 如果你不編寫代碼來處理這些錯誤情況，那么你幾乎肯定最終會遇到bug；你的程序不會總按你的意愿執行。
  
  錯誤產生得原因可以分為以下三種：
• 用戶錯誤。一個好的程序會指出錯誤所在，并幫助用戶來改正它。
• 程序員錯誤。由程序員引入的代碼缺陷。
• 意外情況。
  
• 我們需要一個定義良好的策略來應對我們代碼中的各種錯誤。不論是由人來選擇怎么處理問題，還是由代碼來決定——一定要由某人或者代碼來負責確認錯誤和對錯誤作出反應。
• 錯誤由下層組件提出并向上傳播，以便讓調用方來處理。
  
  錯誤以什么方式提出，稱為錯誤報告機制，可以分為以下幾種：
• 不報告。這是最簡單的情況。絕對不要忽視任何一種情況，如果你不知道如何處理這個問題，就向調用代碼發送一個故障信號，不要對錯誤心存僥幸。
• 返回值。從函數返回一個表示成功或者失敗的值，一個更高級的方法是列舉出所有可能的退出狀態，并返回一個相應的原因代碼，一個值表示成功，其余的值分別代表許多不同的異常終止信息。
• 錯誤狀態變量。這種方法試圖解決函數的返回值和它的錯誤狀態報告之間的矛盾。函數將設置一個共享的全局錯誤變量，而不是返回一個原因代碼。但是這種方法在多線程時會很麻煩。從功能上講，這種技術與使用返回值是等價的，但是它的缺陷之多足夠讓你放棄使用。
• 異常。異常是一種管理錯誤的語言工具；不是所有的語言都支持異常。異常是不能被忽略的，如果沒有被捕獲和處理，異常就會傳播到調用堆棧的最高層，這通常會導致程序崩潰，這使得異常相對于手工編寫的錯誤處理代碼來說更加整潔和安全。處理一個異常的代碼與引發該異常的代碼截然不同，而且可以差的很遠；異常并非沒有開銷，語言對異常的支持會造成性能上的損失。
• 信號。它是一種更加極端的報告機制，主要用于由執行環境向運行程序報告錯誤，信號是硬件中斷的軟件等價物。
  
• 有恢復能力的代碼一定是針對異常安全的，不論出現什么異常，它都必須正確的運行。
• 異常中立的代碼將所有的異常都傳播到調用方，它不會隱藏或者改變任何東西。
• 異常安全分為以下3個等級：1. 基本保證，如果異常在一個函數中發生，它將不會泄露資源，代碼的狀態將保持連貫，但是它不一定會保持一種已知的狀態；2. 強力保證，如果通過你的代碼傳播了一個異常，程序的狀態將保持完全不變；3. 不拋出保證，操作永遠不能拋出異常，如果我們是異常中立的，那么就意味著函數不能執行任何可能會拋出異常的操作。
  
  根據不同的錯誤報告機制，我們有不同的檢測錯誤的方式：
• 返回值。
• 錯誤狀態變量。
• 異常。只有在知道可能會拋出異常的情況下，你才能作出明智的選擇，而只有這已被文檔化的情況下，你才能夠知曉。
• 信號。需要為其安裝一個處理程序。
  
  
  在對一個錯誤進行處理前，我們需要了解錯誤相關的一些關鍵信息：
• 錯誤來自何處。
• 當時的上下文環境。
• 為什么會出錯。
• 錯誤是何時發生的。
• 錯誤的嚴重性。
• 如何修正錯誤。
  
  
• 我們在何時處理錯誤，可以分成兩派：1. 盡可能早的處理，因為錯誤是在其來源附近處理的，所以你可以留住重要的上下文信息，從而使得你的代碼更加清晰，對于返回錯誤代碼的函數來說通常是最佳的選擇；2. 盡可能推遲處理，因為檢測到錯誤的代碼很少知道應該怎樣進行處理，如何處理通常取決于錯誤出現的環境，即調用環境，異常對于這種處理方式很適合。
• 我們在修正錯誤時可能會用到的技巧：1. 日志，日志的作用是記錄程序的生命周期中值得注意的事件，以使你可以深入研究程序內部工作方式和執行的重構路徑；2. 報告，程序應該只在已沒有什么可作的情況下才向用戶報告錯誤；3. 傳播，如果你的代碼遇到了一個錯誤并且不知道該怎么辦，那么就把錯誤向上傳，很可能你的調用方有能力解決這個問題；4. 忽略，如果采取這種方法，必須在代碼中明顯的標記出來。
  
  如果你要提示用戶來解決問題，那么首先應該在頭腦中有一些總體的思路：
• 用戶并不像程序員那么思考，所以以他們所期望的方式來呈現信息。
• 確保你的信息不顯得高深莫測。
• 不要呈現毫無意義的錯誤代碼。
• 將后果嚴重的錯誤與僅僅是警告區分開。
• 只在用戶完全理解每種選擇的后果時在提出問題，如果需要的話，對問題進行一些解釋，使每種選擇的后果都非常清晰。
  
  每個函數中都應該執行的一些錯誤檢查：
• 檢查所有的函數參數。
• 檢查執行過程中關鍵點處的不變條件是否滿足。
• 在使用任何來自外部的值之前都要檢查其有效性。
• 檢查所有系統調用和其他下級函數調用的返回狀態。
  
  
• 在編寫可能會失敗的代碼的同時，編寫所有的錯誤檢測和處理，不要拖延到以后做，如果你很不幸必須推遲處理，至少現在就編寫錯誤檢測部分。
• 既考慮錯誤的引發又考慮錯誤的處理的一般原則是無論故障在什么情況下出現，對于故障的處理都有一個一致的策略。
• 你所編寫的每行代碼都必須在恰當和徹底的錯誤檢查與處理上取得平衡。
• 我們應該如何處理在錯誤處理代碼中發生的錯誤？應該像對待其他任何錯誤一樣，處理那些在錯誤處理程序中發生的錯誤，你會得到一個多層嵌套的錯誤處理程序
  。
• 優秀的程序員：1. 將好的意圖與好的編碼習慣結合在一起；2. 在編寫主要代碼的同時編寫錯誤處理代碼；3. 在他們編寫的代碼中全面覆蓋了所有的錯誤可能性。
• 糟糕的程序員：1. 編寫代碼時很隨便，既不思考也不檢查他們在做什么；2. 忽略在編寫代碼時出現的錯誤；3. 最終不得不進行漫長的調試過程以找到程序崩潰的原因，因為他們從不預先考慮錯誤情況。

轉載于:https://www.cnblogs.com/wing011203/archive/2008/10/19/1314677.html

總結

以上是生活随笔為你收集整理的《编程匠艺》读书笔记之四的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。