轉一些思想 代碼大全的

防護式編程思想 ----《代碼大全》簡要筆記

 

娟子 關注

2016.05.07 16:19* 字數 1098 閱讀 832評論 0喜歡 1

主要思想：

子程序應該不因傳入錯誤數據而被破壞， 哪怕是由其餘子程序產生的錯誤數據；換一種說法是， 程序員應該認可程序都是有問題的都須要被修改。

保護程序免遭非法輸入數據破壞

軟件開發領域「垃圾進，垃圾出」的原則已通過時，應該作到： 垃圾進，什麼都不出；垃圾進，出錯誤提示；不準垃圾進。作法以下：

• 檢查全部來源於外部的值

• 檢查子程序全部輸入參數的值
• 決定如何處理錯誤的輸入數據

Assertions 斷言

在程序開發和使用期間，用於程序自檢的代碼即爲斷言； 使用斷言能夠在程序出現問題時讓程序員更快速的根據斷言給出的信息排查問題和緣由。
斷言一般含有兩個參數：一個描述假設爲真時的狀況的布爾表達式，一個斷言爲假時須要顯示的信息。

創建本身的斷言機制

使用斷言的指導建議

• 用錯誤處理代碼來處理預期會發生的狀況， 用斷言來毫不應該發生的情況
• 避免把須要執行的代碼放到斷言中
• 用斷言來註解並驗證先後條件
• 對於高健壯性的代碼， 應該線使用斷言再處理錯誤

錯誤處理技術

能夠使用的技術：返回中立值；換用下一個正確數據（如讀取數據）；返回與前次相同的數據（如圖像顯示處理）；換用最接近的合法值（超過預設範圍的值）；把警告信息記錄到日誌文件中；返回一個錯誤碼；調用錯誤處理子程序或對象；當錯誤發生時顯示出錯信息；用最穩當的方式在局部處理錯誤；關閉程序。

健壯性與正確性

兩者在某種意義上是相斥的

高層次設計對錯誤處理方式的影響

異常 Exceptions

把代碼中的錯誤和異常事件傳遞給調用方代碼的一種特殊手段。

審慎明智的使用異常：

• 用異常通知程序的其餘部分，發生了不可忽略的錯誤
• 只在真正例外的狀況下才拋出異常
• 不能用異常來推卸責任
• 避免在構造函數和析構函數中拋出異常， 除非你在同一個地方把他們捕獲
• 在恰當的抽象層次拋出異常（如拋出更底層異常）
• 在異常消息中加入致使異常發生的所有信息
• 避免使用空的catch語句
• 瞭解全部函數庫可能拋出的異常
• 考慮建立一個集中地異常報告機制
• 把項目中對異常的使用標準化
• 考慮異常的替換方案

隔離程序，使之包容由錯誤形成的傷害

隔欄，一種代碼的容損策略，如經常使用的： 在輸入數據時將其轉化爲恰當的類型。

輔助調試的代碼

不要自動地把產品版的限制強加於開發版 之上

儘早引入輔助調試的代碼 rails中的 pry、 debugger等

採用進攻式編程

在開發階段讓異常儘可能顯現出來，而在產品真正運行時可以自我修復

計劃移除調試輔助的代碼

• 使用版本控制工具

• 使用內置的預處理器
• 編寫你本身的預處理器
• 使用調試存根

肯定在產品代碼中該保留多少防護式代碼

• 保留那些檢查重要錯誤的代碼

• 去掉檢查細微錯誤的代碼
• 去掉能夠致使程序硬性崩潰的代碼
• 保留可讓程序穩妥崩潰的代碼
• 爲你的技術支持人員記錄錯誤信息
• 確認留在代碼中的錯誤信息是友好的

對防護式變成採起防護式姿態

用防護的姿態適當的因地制宜的使用防護式代碼