差異處
這裏顯示兩個版本的差異處。
下次修改 | 前次修改 | ||
java:effective_java:methods:check_parameters_for_validity [2019/07/14 23:46] tony 建立 |
java:effective_java:methods:check_parameters_for_validity [2023/06/25 09:48] (目前版本) |
||
---|---|---|---|
行 1: | 行 1: | ||
{{tag>java effective_java}} | {{tag>java effective_java}} | ||
- | ====== Effective Java - Check parameters for validity (Working..) ====== | + | ====== Effective Java - Check parameters for validity ====== |
===== Introduction & My Opinion ===== | ===== Introduction & My Opinion ===== | ||
+ | 這個item主要在探討檢查輸入參數是否合法。首先先看看不檢查的後果: | ||
+ | * Constructor: 錯誤的狀態會讓debug變得不容易。 | ||
+ | * Method: (1)拋非預期的例外,通常是NullPointerException,最糟糕的是可以做完但結果不正確。例如傳入10筆要處理的資料但只回傳9筆結果;(2)錯誤的狀態。 | ||
+ | \\ | ||
+ | 而針對處理的建議,主要如下: | ||
+ | * Constructor或是Factory物件: 都應該要檢查,否則會增加debug成本。 | ||
+ | * Method: 應該要檢查,但有幾種例外 1. 不切實際;2. 效能開銷很大; 3. 和後續工作有重疊。 | ||
+ | * 針對拋出的例外,需加上註解說明。 | ||
+ | method中的第二點與第三點的界定很清楚,我比較有疑問的是如何定義不切實際。這種參數檢查如果不如預期,我們通常會拋出IllegalArgumentException、IndexOutOfBoundsException或是NullPointerException;而這種例外屬於programming errors。如果實際狀況根本不可能發生,是否這就代表著不切實際呢? 畢竟如果做這樣子的檢查,我就會需要有對應的測試。因此,目前我的想法如下: | ||
+ | * 如果client code根本不會有這種使用方式,caller method不需要做檢查。 | ||
+ | * 如果是要發佈出去或者是共用機會比較高的API,最好要做檢查。 | ||
+ | \\ | ||
+ | 另外書中有提到一個原則是: 如果參數足夠完成工作,限制應越少越好。這點也滿足Postel's Law所提倡的。 | ||
+ | \\ | ||
+ | \\ | ||
+ | PS. 檢查可以考慮使用Guava的[[https://github.com/google/guava/wiki/PreconditionsExplained|Preconditions]],可以讓你的程式碼看起來較簡潔。 | ||
+ | |||
===== Note ===== | ===== Note ===== | ||
- | Effective Java, 3/e, Item 49。 | + | Effective Java第三版Item 49。 |
===== Reference ===== | ===== Reference ===== | ||
* Effective Java, 3/e | * Effective Java, 3/e |