Null is your firend, not a mistake

原文做者： Roman Elizarov

原文地址： Null is your firend, 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 題解。

更多最新原創文章，掃碼關注我吧！