作為程式設計師的你，程式碼中最多的就是各種方法了，你是如何對引數進行校驗的呢？
背景
大部分的方法和建構函式對傳入的引數值有一些限制，比如：常見的索引值必須是非負數，物件引用不能為空。
你應該使用清晰的文件來標註所有的這些限制，然後在方法體開始的地方強制他們檢查。
應該在錯誤發生的時候儘快的檢查出來，這是基本原則。
如果你不這麼做，當錯誤發生的時候，錯誤將不會被檢測出來，這讓定位錯誤的源頭變得更困難。
如果一個非法引數傳遞到一個方法中，在方法執行前進行了引數檢查。它將會快速失敗，並給出清晰的異常資訊。
如果方法沒有檢查引數，下面這些事情會發生。
| 程度 | 說明 |
|---|---|
| 糟糕 | 方法會在執行過程中失敗然後丟擲一個不明確的異常； |
| 更糟糕 | 方法會正常返回，但是悄悄的計算了一個錯誤的值。 |
| 最糟糕 | 方法正常返回，但是一些物件處在一個不正確的狀態，未來一個不確定的時間點在某些無關聯的點會造成一個錯誤。 |
一句話總結：引數不校驗會導致原子性失敗。
推薦做法
對公共和保護方法，使用java文件的@throws標籤來標註引數值不合法將丟擲的異常。
常見的引數校驗的異常型別如下：
| 異常名稱 | 說明 |
|---|---|
| IllegalArgumentException | 非法引數 |
| IndexOutOfBoundsException | 陣列越界 |
| NullPointerException | 空指標 |
只要你已經已經在文件中標註了方法引數的限制和違反限制會丟擲的異常，限制將是一個簡單的事情，下面是一個典型的例子。
/**
*@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個方法：
| 方法 | 說明 |
|---|---|
| checkFromIndexSize | |
| checkFromToIndex | |
| checkIndex |
這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，這是排序方法應該做的。
所以：這裡有一個小店，在開始的時候檢查列表中的元素應該是可以互相比較的，注意：修改合法性檢查會喪失原子失敗。
偶爾，一個計算執行了一個需要的合法性檢查，但是當執行檢查失敗的時候，丟擲了一個錯誤的異常。換句話說，計算常常會丟擲引數合法性檢查的異常，並不會匹配方法在文件中申明的異常。這種場景下，你應該使用異常翻譯成語。 轉換自然異常為正確的異常。
這個原則並不是說武斷的限制引數是一件好事,而是說：你應該設計通用實際的方法。
假設你的方法接受所有的引數組合而可以做一些合理事情，你的引數限制越少越好，然而，一些限制本質上在抽象類中已經被實現了。
小結
如果看完之後你只能記住一句話：每次你寫一個方法或者一個建構函式，你應該思考引數的限制是否存在，你應該把限制寫在文件中，並在方法體的開始部分確保進行了檢查。
養成這個習慣很重要，適當的工作會在第一次合法性檢查失敗的時候回饋你。
原創不易，關注誠可貴，轉發價更高！轉載請註明出處，讓我們互通有無，共同進步，歡迎溝通交流。