2020年3月17日發佈，Java正式發佈了JDK 14 ，目前已經可以開放下載。在JDK 14中，共有16個新特性，本文主要來介紹其中的一個特性：JEP 358: Helpful NullPointerExceptions
null何錯之有？
對於Java程序員來說，null是令人頭痛的東西。時常會受到空指針異常（NullPointerException）的騷擾。相信很多程序員都特別害怕出現程序中出現NPE，因為這種異常往往伴隨著代碼的非預期運行。
在編程語言中，空引用（Null Reference）是一個與空指針類似的概念，是一個已宣告但其並未引用到一個有效對象的變量。
在Java 1 中就包含了了Null引用和NPE了，但是其實，Null引用是偉大的計算機科學家Tony Hoare 早在1965年發明的，最初作為編程語言ALGOLW的一部分。
1965年，英國一位名為Tony Hoare的計算機科學家在設計ALGOL W語言時提出了null引用的想法。ALGOLW是第一批在堆上分配記錄的類型語言之一。Hoare選擇null引用這種方式，“只是因為這種方法實現起來非常容易”。雖然他的設計初衷就是要“通過編譯器的自動檢測機制，確保所有使用引用的地方都是絕對安全的”，他還是決定為null引用開個綠燈，因為他認為這是為“不存在的值”建模最容易的方式。
但是在2009年，很多年後，他開始為自己曾經做過這樣的決定而後悔不已，把它稱為“一個價值十億美元的錯誤”。實際上，Hoare的這段話低估了過去五十年來數百萬程序員為修復空引用所耗費的代價。因為在ALGOLW之後出現的大多數現代程序設計語言，包括Java，都採用了同樣的設計方式，其原因是為了與更老的語言保持兼容，或者就像Hoare曾經陳述的那樣，“僅僅是因為這樣實現起來更加容易”。
相信很多Java程序員都一樣對null和NPE深惡痛絕，因為他確實會帶來各種各樣的問題。如：
它是錯誤之源。 NullPointerException是目前Java程序開發中最典型的異常。它會使你的代碼膨脹。它讓你的代碼充斥著深度嵌套的null檢查，代碼的可讀性糟糕透頂。它自身是毫無意義的。 null自身沒有任何的語義，尤其是是它代表的是在靜態類型語言中以一種錯誤的方式對缺失變量值的建模。它破壞了Java的哲學。 Java一直試圖避免讓程序員意識到指針的存在，唯一的例外是:null指針。它在Java的類型系統上開了個口子。null並不屬於任何類型，這意味著它可以被賦值給任意引用類型的變量。這會導致問題，原因是當這個變量被傳遞到系統中的另一個部分後，你將無法獲知這個null變量最初賦值到底是什麼類型。其他語言如何解決NPE問題
我們知道，出了Java語言外，還有很多其他的面嚮對象語言，那麼在其他的一些語言中，是如何解決NPE的問題的呢？
如在Groovy中使用安全導航操作符（Safe Navigation Operator）可以訪問可能為null的變量：
defcarInsuranceName = person?.car?.insurance?.name
Groovy的安全導航操作符能夠避免在訪問這些可能為null引用的變量時發生NullPointerException，在調用鏈中的變量遭遇null時將null引用沿著調用鏈傳遞下去，返回一個null。
其實這個功能曾經考慮過增加一個類似的功能，但是後來又被捨棄了。
另外，在Haskell和Scala也有類似的替代品，如Haskell中的Maybe類型、Scala中的Option[T]。
在 Kotlin 中，其類型系統嚴格區分一個引用可以容納 null 還是不能容納。也就是說，一個變量是否可空必須顯示聲明，對於可空變量，在訪問其成員時必須做空處理，否則無法編譯通過：
var a: String = "abc"a = null// 編譯錯誤
如果允許為空，可以聲明一個可空字符串，寫作 String?：
var b: String? = "abc"//String? 表示該 String 類型變量可為空b = null// 編譯通過
看到這個？的時候，是不是發現和Groovy有點像？不過還是有一定區別的，這裡就不展開了。
好了，書歸正傳，我們來看看作為一個TOIBE編程語言排行榜第一名的語言，Java語言對於NPE做出了哪些努力！
Java做了哪些努力
一直以來對於null和NPE的改進還是做出了一些努力的。
首先在Java 8中提供了Optional，其實在Java 8 推出之前，Google的Guava庫中就率先提供過Optional接口來使null快速失敗。
Optional在可能為null的對象上做了一層封裝，Optional對象包含了一些方法來顯式地處理某個值是存在還是缺失，Optional類強制你思考值不存在的情況，這樣就能避免潛在的空指針異常。
但是設計Optional類的目的並不是完全取代null，它的目的是設計更易理解的API。通過Optional，可以從方法簽名就知道這個函數有可能返回一個缺失的值，這樣強制你處理這些缺失值的情況。
另外一個值得一提的就是最近（2020年03月17日）發佈的JDK 14中對於NPE有了一個增強。那就是JEP 358: Helpful NullPointerExceptions
更有幫助的NPE
JDK 14中對於NEP有了一個增強，既然NPE暫時無法避免，那麼就讓他對開發者更有幫助一些。
每個Java開發人員都遇到過NullPointerExceptions (NPEs)。由於NPEs可以發生在程序的幾乎任何地方，試圖捕獲並從它們中恢復通常是不切實際的。因此，開發人員通常依賴於JVM來確定NPE實際發生時的來源。例如，假設在這段代碼中出現了一個NPE:
a.i = 99;
JVM將打印出導致NPE的方法、文件名和行號:
Exceptioninthread "main" java.lang.NullPointerExceptionatProg.main(Prog.java:5)
通過以上堆棧信息，開發人員可以定位到a.i= 99這一行，並推斷出a一定是null。
但是，對於更復雜的代碼，如果不使用調試器，就不可能確定哪個變量是null。假設在這段代碼中出現了一個NPE:
a.b.c.i = 99;
我們根本無法確定到底是a還是b或者是c在運行時是個null值。
但是，在JDK14以後，這種窘境就有解了。
在JDK14中，當運行期，試圖對一個bull對象進行應用時，JVM依然會拋出一個NullPointerException (NPE)，除此之外，還會通過通過分析程序的字節碼指令，JVM將精確地確定哪個變量是null，並且在堆棧信息中明確的提示出來。
在JDK 14中，如果上文中的a.i = 99發生NPE，將會打印如下堆棧：
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導致了空指針，則會打印以下堆棧信息：
Exception in thread "main" java.lang.NullPointerException: Cannot read field "c" because "a.b" is null at Prog.main(Prog.java:5)
可見，堆棧中明確指出了到底是哪個對象為null而導致了NPE，這樣，一旦應用中發生NPE，開發者可以通過堆棧信息第一時間定位到到底是代碼中的那個對象為null導致的。
這算是JDK的一個小小的改進，但是這個改進對於開發者來說確實是非常友好的。
閱讀更多 異步社區 的文章
