原文作者： Roman Elizarov
原文地址： Null is your friend, not a mistake
譯者：秉心說
Kotlin Island from Wikimedia by Pavlikhin, CC BY-SA 4.0
我使用 Java 語言編程已經很久很久了，掌握了通過 Java 撰寫和維護大型軟體（百萬行代碼）應該注意些什么，并親眼目睹了全行業都在竭力避免空指標例外 NullPointerException（NPE），它困擾著大大小小的 Java 類別庫，在 2009 年其發明者 Tony Hoare 承認空參考是他造成的一個 “十億美元的錯誤”之前，人人已經意識到它的危險性，
在 1996 年 Java 1.0 發布時，這個問題還不是如此明顯，讓我們看一個典型的 Java API 的例子：File.list() 方法，它被用來列舉檔案夾中的內容，如下所示：
for(String name : new File("directory").list()) {
System.out.println(name);
}
僅當檔案夾存在時上面的代碼才會正常運行，否則將拋出 NPE，因為 list() 回傳了 null，但是誰會寫這樣的代碼呢？不僅僅 list() 方法的檔案中清楚的說明了檔案夾不存在時將回傳 null，而且現代的 IDE 也會對特定的代碼給你提出警告，
但是，當使用 Java 編程時，開發者經常犯這類錯誤，到目前為止，有大量研究表明它們是如何發生的，結果表明，大多數情況下，我們的 API 函式不應該回傳 null，其他開發者也并不希望回傳 null，在一些特殊情況下，比如預設值，Java 中的慣例是回傳一些 “空物件”（空集合，未填充的物件等等），或者拋出例外，比回傳 null 更糟糕，這就是為什么要設計 Files.newDirectoryStream, 高級版本的 File.list，任何情況都不會出現 null，
所以當 null 在一些特殊情況下作為函式回傳值時，如性能優化，未初始化的參考欄位等等，它常常會讓你措手不及，沒有做好準備去處理它，不僅僅是必須處理空值的情況很少，而且在 Java 中用來處理空值的代碼是很啰嗦的：
String[] list = new File("directory").list();
if (list != null) {
for (String name : list) {
System.out.println(name);
}
}
毫無疑問，除非真的需要（你的客戶在生產環境發現了 NPE），不然你真的不想寫這樣的代碼，
對 null 的恐懼導致了一些極端情況，有一些 Java 編碼風格完全禁止 null，將可惡的作業交給開發者，不知道你有沒有見過這樣的 Java 類別庫，所有的域物件都要實作一個特殊的 Null 介面，并且提供手動編碼生成的 “空物件” 實體，如果沒有見過說明你還是幸運的，但是我敢打賭你已經看到了只為了避免空值而污染 Java 代碼的 Optional <T> 包裝器（譯者注：Java 8 新特性），
有些集合框架的 API 出于謹慎禁止 null 元素，并且一些 Java 核心團隊成員認為 Java 集合框架對 null 的支持是一個錯誤，這讓人非常難過，
事實上，null 這個概念不是一個錯誤，但是 Java 的型別系統認為 null 是任何型別的成員， 讓我們看看，在 Java 中 “abc” 是一個合法的 String，null 也是一個合法的 String，你可以在前者上使用 string 的所有方法，例如 substring，但是在后者上使用則會發生運行時錯誤，它是型別安全的嗎？并不完全是，一個型別的特定值在進行某些操作時發生運行時例外（例如除 0）是正常的，但是當對一個值進行該型別的所有操作都發生了例外，這首先表明的是這個值并不屬于這個型別，所有的那些 NPE 都表明了 Java 的型別系統存在明顯的缺陷，
更多的型別安全的編程語言，例如 Kotlin，通過合理的將 null 的概念合并到型別系統中來修復這個缺陷，添加檢查和警告也有一定作用，但這并不夠，顯然，一個健全的型別系統必須允許 String 型別的所有變數都支持它的操作，所以在 Kotlin 中，將 null 賦給 String 型別的變數就不僅僅只是一個警告了，而是型別錯誤，就像把數值 42 賦給 String 型別變數一樣，
型別系統中合理的 null 支持是 API 設計的一個轉折點，沒有任何理由再去害怕 null 了，一些函式回傳可空型別 String?，另一些函式回傳不可空型別 String，就和一些函式回傳 String，另一些回傳 Int 一樣，它們都是不同的型別，有著不同但是安全的操作集，
用型別安全的 null 來表示 “缺失的值” 是更好，更高效，更簡潔的，看一下 Kotlin 標準庫中的 String.toIntOrNull() 函式，用于將 string 轉為數字，不能轉換的話回傳 null，使用起來很愉快，撰寫一個命令列程式，接受 integer 引數并處理引數的缺失就很簡單：
fun main(args: Array<String>) {
val id = args.getOrNull(0)?.toIntOrNull()
?: error("id expected")
// ...
}
在 API 設計中使用 null 吧，它是你和 Kotlin 的好朋友，沒有理由去害怕它，也沒有理由使用 null object 模式或者包裝器來處理它，更不用說例外了，在你的 API 中合理使用 null 會給你帶來更可讀，更安全的代碼，并且遠離樣板代碼，
深入閱讀
如果你喜歡這個主題，并且想了解更多關于語言設計的細節，那么可以考慮閱讀這篇文章—— Dealing with absence of value ，
文章首發微信公眾號：
秉心說， 專注 Java 、 Android 原創知識分享，LeetCode 題解，更多最新原創文章，掃碼關注我吧！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/60338.html
標籤：Android
上一篇：Android studio初次安裝啟動時彈出unable to access android sdk add-on list提示的解決方法
下一篇：Android 布局陰影實作