第六章 人非圣賢

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

轉(zhuǎn)載于:https://www.cnblogs.com/wing011203/archive/2008/10/19/1314677.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。