原文作者： "Roman Elizarov" 原文地址： "Null is your firend, not a mistake" 譯者：秉心說 "Kotlin Island from Wikimedia by Pavlikhin, CC BY SA 4.0" 我使用 Java 語言編程已經很久很久 ...
原文作者： 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 題解。更多最新原創文章，掃碼關註我吧！
