去掉煩人的「!=null"(判空語句)

這是初、中級程序猿常常會遇到的問題。他們總喜歡在方法中返回null，所以，在調用這些方法時，也不得不去判空。另外，也許受此習慣影響，他們總潛意識地認爲，全部的返回都是不可信任的，爲了保護本身程序，就加了大量的判空。

吐槽完畢，回到這個題目自己，進行判空前，請區分如下兩種狀況：

1. null 是一個有效有意義的返回值(Where null is a valid response in terms of the contract; and)

2. null是無效有誤的(Where it isn't a valid response.)

你可能還不明白這兩句話的意思，不急，繼續往下看，接下來將詳細討論這兩種狀況

先說第2種狀況

null就是一個不合理的參數，就應該明確地中斷程序，往外拋錯誤。這種狀況常見於api方法。例如你開發了一個接口，id是一個必選的參數，若是調用方沒傳這個參數給你，固然不行。你要感知到這個狀況，告訴調用方「嘿，哥們，你傳個null給我作甚"。

相對於判空語句，更好的檢查方式有兩個

1. assert語句，你能夠把錯誤緣由放到assert的參數中，這樣不只能保護你的程序不往下走，並且還能把錯誤緣由返回給調用方，豈不是一箭雙鵰。

2. 也能夠直接拋出空指針異常。上面說了，此時null是個不合理的參數，有問題就是有問題，就應該大大方方往外拋。

第1種狀況會更復雜一些。

這種狀況下，null是個」看上去「合理的值，例如，我查詢數據庫，某個查詢條件下，就是沒有對應值，此時null算是表達了「空」的概念。

這裏給一些實踐建議：

• 假如方法的返回類型是collections，當返回結果是空時，你能夠返回一個空的collections（empty list),而不要返回null.這樣調用側就能大膽地處理這個返回，例如調用側拿到返回後，能夠直接print list.size()，又無需擔憂空指針問題。（什麼？想調用這個方法時，不記得以前實現該方法有沒按照這個原則？因此說，代碼習慣很重要！若是你養成習慣，都是這樣寫代碼（返回空collections而不返回null)，你調用本身寫的方法時，就能大膽地忽略判空）

• 若是要用equal方法，請用object<不可能爲空>.equal(object<可能爲空>)) 例如： 使用 "bar".equals(foo) 而不是 foo.equals("bar")