檢查參數的有效性（38）

一、絕大多數方法和構造器對於傳遞給他們的參數都會有某種限制

• 請在文檔開頭處清楚指明這些限制，在方法體開頭檢查參數，強制施加這些限制
• 不然會出現各類異常
• 最可怕的是沒出現異常，返回的是錯誤結果

二、對於公有方法

• 在JavaDoc 中加入@throws 說明違反會拋出什麼異常

非公有方法：

• 使用斷言 檢查參數
• 這些斷言是聲稱被斷言條件將會爲真，不管外圍包客戶端怎麼使用它
• 斷言失敗會拋出AssertionError
• 正常發佈的代碼都是斷言無效的，即正常發佈的代碼中斷言語句都不執行的（或不起做用的）
• 當執行代碼時，使用-ea選項使斷言有效，也可使用-da選項使斷言無效（默認爲無效）

三、有些參數方法並沒用到，保存起來供後續調用使用

• 這種狀況更加須要有效性檢查，否則後面報錯排查起來很費勁
• 構造器是將參數保存起來以備後續使用的表明情形

四、執行計算任務前，先檢查參數這一規定也有例外

• 有時有效性檢查工做很是昂貴，或已經隱含着計算過程當中
• 好比：Collections.sort(List ) ，sort 會對每一個元素進行比較，提早檢查沒有意義

五、有些時候，某些計算會進行隱式的執行必要的有效性檢查

• 這種狀況拋出的異常可能與文檔中標明的異常不相符
• 使用61條的異常轉譯技術，轉爲對應的異常

六、不是對參數的任何限制都是件好事

• 可以正常工做的狀況下，限制越少越好

七、總結

• 編寫方法和構造器時，應該考慮它的參數有哪些限制
• 應該把限制寫到文檔中
• 顯式的檢查來實施這些限制