## 第8章 ：防御式編程 > checklist For Defensive Programming ### 核對表：防御式編程 ------ ### 一般事宜 - 子程序是否保護自己免遭有害輸入數據的破壞？ - 你用斷言來說明編程假定嗎？其中包括了前條件和后條件嗎？ - 斷言是否只是用來說明從不應該發生的情況？ - 你是否在架構或高層設計中規定了一組特定的錯誤處理技術？ - 你是否在架構或高層設計中規定了是讓錯誤處理更傾向于健壯性還是正確性？ - 你是否建立了隔欄來遏制錯誤可能造成的破壞？是否減少了其他需要關注錯誤處理的代碼的數量？ - 代碼中用到輔助調試的代碼了嗎？ - 如果需要啟用或禁用添加的輔助助手的話，是否無需大動干戈？ - 在防御式編程時映入的代碼量是否適宜–既不過多，也不過少？ - 在開發階段是否采用了進攻式編程來使錯誤難以被忽視？ ### 異常 - 你在項目中定義了一套標準化的異常處理方案嗎？ - 是否考慮過異常之外的其他替代方案？ - 如果可能的話，是否在局部處理了錯誤而不是把它當成一個異常拋到外部？ - 代碼中是否避免了在構造函數和析構函數中拋出異常？ - 所有的異常是否都與拋出它們的子程序處于同一抽象層次上？6).每個異常是否都包含了關于異常發生的所有背景信息？ - 代碼中是否沒有使用空的catch語句？(或者如果使用空的catch語句確實很合適，那么明確說明了嗎？) ### 安全事宜 - 檢查有害輸入數據的代碼是否也檢查了故意的緩沖區溢出、SQL注入、HTML注入、證書溢出一級其他惡意輸入數據？ - 是否檢查了所有的錯誤返回碼 - 是否捕獲了所有的異常？ - 出錯消息中是否避免出現有助于攻擊者攻入系統所需的信息？ ### 中文要點： - 最終產品代碼中對錯誤的處理方式要比“垃圾進，垃圾出”復雜的多。 - 防御式編程技術可以讓錯誤更容易發現、更容易修改，并減少錯誤對產品代碼的破壞。 - 斷言可以幫助人盡早發現錯誤，尤其是在大型系統和高可靠性的系統中，以及快速變化的代碼中。 - 關于如何處理錯誤輸入的決策是一項關鍵的錯誤處理決策，也是一項關鍵的高層設計決策。 - 異常提供了一種與代碼正常流程角度不同的錯誤處理手段。如果留心使用異常，它可以成為程序員們知識工具箱中的一項有益補充，同時也應該在異常和其他錯誤處理手段之間進行權衡比較。 - 針對產品代碼的限制并不適用于開發中的軟件。你可以利用這一優勢在開發中添加有助于更快地排查錯誤的代碼。 ### English Key Points： - Production code should handle errors in a more sophisticated way than “garbage in, garbage out.” - Defensive-programming techniques make errors easier to find, easier to fix, and less damaging to production code. - Assertions can help detect errors early, especially in large systems, high reliability systems, and fast-changing code bases. - The decision about how to handle bad inputs is a key error-handling decision, and a key high-level design decision. - Exceptions provide a means of handling errors that operates in a different dimension from the normal flow of the code.They are a valuable addition to the programmer’s toolkit when used with care, and should be weighed against other error-processing techniques. - Constraints that apply to the production system do not necessarily apply to the development version. You can use that to your advantage, adding code to the development version that helps to flush out errors quickly.