2020年3月17日發(fā)布，Java正式發(fā)布了JDK 14 ，目前已經(jīng)可以開放下載。在JDK 14中，共有16個(gè)新特性，本文主要來介紹其中的一個(gè)特性：JEP 358: Helpful NullPointerExceptions

創(chuàng)新互聯(lián)建站主要從事網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)河源,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

null何錯(cuò)之有？

對于Java程序員來說，null是令人頭痛的東西。時(shí)常會(huì)受到空指針異常（NullPointerException）的騷擾。相信很多程序員都特別害怕出現(xiàn)程序中出現(xiàn)NPE，因?yàn)檫@種異常往往伴隨著代碼的非預(yù)期運(yùn)行。

在編程語言中，空引用（Null Reference）是一個(gè)與空指針類似的概念，是一個(gè)已宣告但其并未引用到一個(gè)有效對象的變量。

在Java 1 中就包含了了Null引用和NPE了，但是其實(shí)，Null引用是偉大的計(jì)算機(jī)科學(xué)家Tony Hoare 早在1965年發(fā)明的，最初作為編程語言ALGOL W的一部分。

1965年，英國一位名為Tony Hoare的計(jì)算機(jī)科學(xué)家在設(shè)計(jì)ALGOL W語言時(shí)提出了null引用的想法。ALGOL W是第一批在堆上分配記錄的類型語言之一。Hoare選擇null引用這種方式，“只是因?yàn)檫@種方法實(shí)現(xiàn)起來非常容易”。雖然他的設(shè)計(jì)初衷就是要“通過編譯器的自動(dòng)檢測機(jī)制，確保所有使用引用的地方都是絕對安全的”，他還是決定為null引用開個(gè)綠燈，因?yàn)樗J(rèn)為這是為“不存在的值”建模最容易的方式。

但是在2009年，很多年后，他開始為自己曾經(jīng)做過這樣的決定而后悔不已，把它稱為“一個(gè)價(jià)值十億美元的錯(cuò)誤”。實(shí)際上，Hoare的這段話低估了過去五十年來數(shù)百萬程序員為修復(fù)空引用所耗費(fèi)的代價(jià)。因?yàn)樵贏LGOL W之后出現(xiàn)的大多數(shù)現(xiàn)代程序設(shè)計(jì)語言，包括Java，都采用了同樣的設(shè)計(jì)方式，其原因是為了與更老的語言保持兼容，或者就像Hoare曾經(jīng)陳述的那樣，“僅僅是因?yàn)檫@樣實(shí)現(xiàn)起來更加容易”。

相信很多Java程序員都一樣對null和NPE深惡痛絕，因?yàn)樗_實(shí)會(huì)帶來各種各樣的問題（來自《Java 8 實(shí)戰(zhàn)》）。如：

• 它是錯(cuò)誤之源。 NullPointerException是目前Java程序開發(fā)中最典型的異常。它會(huì)使你的代碼膨脹。
• 它讓你的代碼充斥著深度嵌套的null檢查，代碼的可讀性糟糕透頂。
• 它自身是毫無意義的。 null自身沒有任何的語義，尤其是是它代表的是在靜態(tài)類型語言中以一種錯(cuò)誤的方式對缺失變量值的建模。
• 它破壞了Java的哲學(xué)。 Java一直試圖避免讓程序員意識(shí)到指針的存在，唯一的例外是:null指針。
• 它在Java的類型系統(tǒng)上開了個(gè)口子。 null并不屬于任何類型，這意味著它可以被賦值給任意引用類型的變量。這會(huì)導(dǎo)致問題， 原因是當(dāng)這個(gè)變量被傳遞到系統(tǒng)中的另一個(gè)部分后，你將無法獲知這個(gè)null變量最初賦值到底是什么類型。

其他語言如何解決NPE問題

我們知道，出了Java語言外，還有很多其他的面向?qū)ο笳Z言，那么在其他的一些語言中，是如何解決NPE的問題的呢？

如在Groovy中使用安全導(dǎo)航操作符（Safe Navigation Operator）可以訪問可能為null的變量：

def carInsuranceName = person?.car?.insurance?.name

Groovy的安全導(dǎo)航操作符能夠避免在訪問這些可能為null引用的變量時(shí)發(fā)生NullPointerException，在調(diào)用鏈中的變量遭遇null時(shí)將null引用沿著調(diào)用鏈傳遞下去，返回一個(gè)null。

其實(shí)這個(gè)功能曾經(jīng)考慮過增加一個(gè)類似的功能，但是后來又被舍棄了。

另外，在Haskell和Scala也有類似的替代品，如Haskell中的Maybe類型、Scala中的Option[T]。

在 Kotlin 中，其類型系統(tǒng)嚴(yán)格區(qū)分一個(gè)引用可以容納 null 還是不能容納。也就是說，一個(gè)變量是否可空必須顯示聲明，對于可空變量，在訪問其成員時(shí)必須做空處理，否則無法編譯通過：

var a: String = "abc"
a = null // 編譯錯(cuò)誤

果允許為空，可以聲明一個(gè)可空字符串，寫作 String?：

var b: String? = "abc" //String? 表示該 String 類型變量可為空
b = null // 編譯通過

看到這個(gè)？的時(shí)候，是不是發(fā)現(xiàn)和Groovy有點(diǎn)像？不過還是有一定區(qū)別的，這里就不展開了。

好了，書歸正傳，我們來看看作為一個(gè)TOIBE編程語言排行榜第一名的語言，Java語言對于NPE做出了哪些努力！

Java做了哪些努力

一直以來對于null和NPE的改進(jìn)還是做出了一些努力的。

首先在Java 8中提供了Optional，其實(shí)在Java 8 推出之前，Google的Guava庫中就率先提供過Optional接口來使null快速失敗。

Optional在可能為null的對象上做了一層封裝，Optional對象包含了一些方法來顯式地處理某個(gè)值是存在還是缺失，Optional類強(qiáng)制你思考值不存在的情況，這樣就能避免潛在的空指針異常。

但是設(shè)計(jì)Optional類的目的并不是完全取代null，它的目的是設(shè)計(jì)更易理解的API。通過Optional，可以從方法簽名就知道這個(gè)函數(shù)有可能返回一個(gè)缺失的值，這樣強(qiáng)制你處理這些缺失值的情況。

關(guān)于Optional的用法，不是本文的重點(diǎn)，就不在這里詳細(xì)介紹了，筆者在日常開發(fā)中經(jīng)常結(jié)合Stream一起使用Optional，還是比較好用的。

另外一個(gè)值得一提的就是最近（2020年03月17日）發(fā)布的JDK 14中對于NPE有了一個(gè)增強(qiáng)。那就是JEP 358: Helpful NullPointerExceptions

更有幫助的NPE

JDK 14中對于NEP有了一個(gè)增強(qiáng)，既然NPE暫時(shí)無法避免，那么就讓他對開發(fā)者更有幫助一些。

每個(gè)Java開發(fā)人員都遇到過NullPointerExceptions (NPEs)。由于NPEs可以發(fā)生在程序的幾乎任何地方，試圖捕獲并從它們中恢復(fù)通常是不切實(shí)際的。因此，開發(fā)人員通常依賴于JVM來確定NPE實(shí)際發(fā)生時(shí)的來源。例如，假設(shè)在這段代碼中出現(xiàn)了一個(gè)NPE:

a.i = 99;

JVM將打印出導(dǎo)致NPE的方法、文件名和行號(hào):

Exception in thread "main" java.lang.NullPointerException
at Prog.main(Prog.java:5)

通過以上堆棧信息，開發(fā)人員可以定位到a.i= 99這一行，并推斷出a一定是null。

但是，對于更復(fù)雜的代碼，如果不使用調(diào)試器，就不可能確定哪個(gè)變量是null。假設(shè)在這段代碼中出現(xiàn)了一個(gè)NPE:

a.b.c.i = 99;

我們根本無法確定到底是a還是b或者是c在運(yùn)行時(shí)是個(gè)null值。

但是，在JDK14以后，這種窘境就有解了。

在JDK14中，當(dāng)運(yùn)行期，試圖對一個(gè)bull對象進(jìn)行應(yīng)用時(shí)，JVM依然會(huì)拋出一個(gè)NullPointerException (NPE)，除此之外，還會(huì)通過通過分析程序的字節(jié)碼指令，JVM將精確地確定哪個(gè)變量是null，并且在堆棧信息中明確的提示出來。

在JDK 14中，如果上文中的a.i = 99發(fā)生NPE，將會(huì)打印如下堆棧：

Exception in thread "main" java.lang.NullPointerException:
Cannot assign field "i" because "a" is null
at Prog.main(Prog.java:5)

如果是a.b.c.i = 99;中的b為null導(dǎo)致了空指針，則會(huì)打印以下堆棧信息：

Exception in thread "main" java.lang.NullPointerException:
Cannot read field "c" because "a.b" is null
at Prog.main(Prog.java:5)

可見，堆棧中明確指出了到底是哪個(gè)對象為null而導(dǎo)致了NPE，這樣，一旦應(yīng)用中發(fā)生NPE，開發(fā)者可以通過堆棧信息第一時(shí)間定位到到底是代碼中的那個(gè)對象為null導(dǎo)致的。

這算是JDK的一個(gè)小小的改進(jìn)，但是這個(gè)改進(jìn)對于開發(fā)者來說確實(shí)是非常友好的。真的希望這些小而美的改動(dòng)可以在JDK中越來越多。

參考資料：

https://openjdk.java.net/jeps/358

《Java 8 In Action》

到此這篇關(guān)于Java14發(fā)布了,再也不怕NullPointerException了的文章就介紹到這了,更多相關(guān)Java14 NullPointerException內(nèi)容請搜索創(chuàng)新互聯(lián)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持創(chuàng)新互聯(lián)！