程式設計師你如何檢查參數的合法性？

• 2020 年 9 月 14 日
• 筆記
• JAVA, 職業心情

作為程式設計師的你，程式碼中最多的就是各種方法了，你是如何對參數進行校驗的呢？

背景

大部分的方法和構造函數對傳入的參數值有一些限制，比如：常見的索引值必須是非負數，對象引用不能為空。

你應該使用清晰的文檔來標註所有的這些限制，然後在方法體開始的地方強制他們檢查。

應該在錯誤發生的時候儘快的檢查出來，這是基本原則。

如果你不這麼做，當錯誤發生的時候，錯誤將不會被檢測出來，這讓定位錯誤的源頭變得更困難。

如果一個非法參數傳遞到一個方法中，在方法執行前進行了參數檢查。它將會快速失敗，並給出清晰的異常資訊。

如果方法沒有檢查參數，下面這些事情會發生。

一句話總結：參數不校驗會導致原子性失敗。

推薦做法

對公共和保護方法，使用java文檔的@throws標籤來標註參數值不合法將拋出的異常。

常見的參數校驗的異常類型如下：

只要你已經已經在文檔中標註了方法參數的限制和違反限制會拋出的異常，限制將是一個簡單的事情，下面是一個典型的例子。

/**
*@param m 必須是正整數
*@throws ArithmeticException 如果m<=0
**/
public BigInteger mod(BigInteger m){
	if(m<=0){
    	throw new ArithmeticException("modulus <=0: "+ m);
    }
    //todo 其它程式碼
}

注意：

文檔注釋並沒有說， 如果m是空，mod將拋出NullPointException， 儘管這個方法確實會這樣。調用m.signum()的時候這個異常被標註在類級別BigInteger的文檔注釋上，類級別的注釋適用於所有的公共方法的參數，這是一個避免在每個方法單獨的文檔化標註NullPointException這種混亂的好方法。

也許可以結合@Nullable或者類似的註解來指明特殊參數可以為空，但是這個實踐並不是標準的，並且有很多註解可以用來達到這個目的。

Objects實用類

Objects.requireNonNull方法，在Java7中添加的，非常的靈活和方便，所以沒有理由手動的執行空指針檢查。 你也可以指定異常的詳細資訊，這個方法返回自己的輸入，所以你可以在使用該值的時候執行一個空指針檢查。

//一行程式碼使用java的空指針檢查
this.strategy = Objects.requireNonNull(strategy,"strategy")

如果你可以忽略返回值，你也可以根據你的需要使用Objects.requireNonNull作為獨立的空指針檢查。
在Java9中，一個範圍檢查的方法被添加到了java.util.Objects中，包含了3個方法：

這3個方法沒有空指針檢查方法靈活，它無法讓你指定自己的異常詳細資訊，它被設計用在List和Array的索引檢查上。
它也無法處理閉區間，但是只要你需要，這就是一個小便利。

Java斷言

對一個不開放的方法，你作為包的作者，控制著方法的調用狀況，你必須保證只有合法的參數值傳遞進去了。所以，對非公開的方法，你可以使用斷言來進行參數檢查，如下所示：

//私有幫助排序函數
private static void sort(long a[] , int offset, int length){
	assert a != null ;
    //更多程式碼
}

本質上來講，斷言申明條件一定是true , 忽略客戶端如何使用對應的包。
跟一般的合法性檢查不同，斷言失敗的時候拋出AssertError；
跟一般的合法性檢查不同，除非你啟用他們否則斷言對你沒有任何影響和消耗。
在java命令行啟用指令：

-ea
或者
-enableassertions

更多斷言的資訊，查看java手冊的Asserts;

檢查參數的合法性非常重要，即使你的方法中沒有用到，但是存儲起來了，後面會用到。

舉個例子： 靜態工廠方法： 輸入一個 int數組 ，返回一個array的 list視圖， 如果客戶端傳入 null, 這個方法會拋出NPE, 因為方法會有一個直接檢查，調用了Objects.requireNonNull。
如果忽略檢查，方法會返回一個引用新創建的List的實例；

而客戶端嘗試使用的時候回拋出NPE; 這個時候，原始的List實例很難決定，很大可能會複雜到變成一個調試任務。

構造函數代表了一個特殊例子的原則： 你應該檢查即將存儲稍後會用到的參數的合法性。

檢查構造函數參數的合法性非常重要，它可以防止構造一個違反類的不變性的對象。

異常情況

在執行方法計算之前，你應該檢查方法參數 。 這個規則也有異常情況。

一個重要的異常情況是：合法性檢查代價非常高並且重要， 並且檢查是在執行計算的過程中執行的。
舉個例子：有一個方法對一個對象list排序，比如 Collectios.sort(list),所有的list中的對象必須是可互相比較的。在處理list比較的時候,每個對象將會跟其它的對象進行比較，

如果對象不能互相比較，其中一個或多個比較會拋出ClassCastException，這是排序方法應該做的。

所以：這裡有一個小店，在開始的時候檢查列表中的元素應該是可以互相比較的，注意：修改合法性檢查會喪失原子失敗。

偶爾，一個計算執行了一個需要的合法性檢查，但是當執行檢查失敗的時候，拋出了一個錯誤的異常。換句話說，計算常常會拋出參數合法性檢查的異常，並不會匹配方法在文檔中申明的異常。這種場景下，你應該使用異常翻譯成語。 轉換自然異常為正確的異常。

這個原則並不是說武斷的限制參數是一件好事,而是說：你應該設計通用實際的方法。
假設你的方法接受所有的參數組合而可以做一些合理事情，你的參數限制越少越好，然而，一些限制本質上在抽象類中已經被實現了。

小結

如果看完之後你只能記住一句話：每次你寫一個方法或者一個構造函數，你應該思考參數的限制是否存在，你應該把限制寫在文檔中，並在方法體的開始部分確保進行了檢查。

養成這個習慣很重要，適當的工作會在第一次合法性檢查失敗的時候回饋你。

原創不易，關注誠可貴，轉發價更高！轉載請註明出處，讓我們互通有無，共同進步，歡迎溝通交流。