Java14 真的太香了,NullPointerException的處理新方式

Java14 真的太香了,NullPointerException的處理新方式

 

在Java語言中,處理空指針往往是一件很頭疼的事情,一不小心,說不定就搞出個線上Bug,讓你的績效考覈拿到3.25。

最近新出的Java14,相信大家都有所耳聞,那麼今天就來看看,面對NullPointerException,Java14有哪些更好的處理方式呢?

1.傳統的 NullPointerException

我們編碼過程中呢,經常會使用鏈式調用的方式來寫代碼,這樣寫起來很方便,也很清晰,但是,一旦出現NullPointerException,那就頭大了,因爲你很難知道異常是在什麼時候開始發生的。

舉個簡單的例子,就比如下面的代碼,要找到公司某個員工的戶籍所在地,我們這樣來調用

String city = employee.getDetailInfos().getRegistryAddress().getCity();  

在鏈式調用的過程中,如果employee,getDetailInfos(),或者getRegistryAddress()爲空,JVM就會拋出NullPointerException

那麼導致異常的根本原因是什麼?如果不使用調試器,很難確定哪個變量爲空。而且,JVM也只會打印導致異常的方法、文件名和行號,僅此而已。那麼下面,我將帶大家瞭解Java 14如何通過JEP 358解決這個問題。

2.增強型 NullPointerException

SAP在2006年爲其商業JVM實現了增強型的NullPointerException。2019年2月,它被提議作爲OpenJDK社區的一個增強,之後很快,它成爲了一個JEP。所以,該功能在2019年10月完成並在JDK 14版本推出

本質上,JEP 358 旨在通過描述某個變量是 “null”來提高 JVM 生成的 “NullPointerException” 的可讀性。JEP 358通過在方法、文件名和行號旁邊描述爲null的變量,帶來了一個詳細的NullPointerException消息。它通過分析程序的字節碼指令來工作。因此,它能夠精確地確定哪個變量或表達式是null。最重要的是,JDK 14中默認關閉詳細的異常消息。要啓用它,我們需要使用命令行選項:

-XX:+ShowCodeDetailsInExceptionMessages  

2.1 詳細的異常信息

考慮在激活ShowCodeDetailsInExceptionMessages標誌的情況下再次運行代碼:

Exception in thread "main" java.lang.NullPointerException:  
  Cannot invoke "RegistryAddress.getCity()" because the return value of  
"com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$DetailInfos.getRegistryAddress()" is null  
  at com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException.main(HelpfulNullPointerException.java:10)  

這一次,從附加信息中,我們知道員工的個人詳細信息丟失的註冊地址導致了我們的異常。從這個增強中獲得的信息可以節省我們調試所用的時間。

JVM由兩部分組成詳細的異常消息。第一部分表示失敗的操作,這是引用爲null的結果,而第二部分表示了null引用的原因:

Cannot invoke "String.toLowerCase()" because the return value of "getEmailAddress()" is null  

爲了生成異常消息,JEP 358 重構了將空引用推送到操作數堆棧上的部分源代碼。

3. 技術方面

現在我們已經很好地理解了如何使用增強的NullPointerException_s標識 _null引用,讓我們來看看它的一些技術方面。

首先,只有當JVM本身拋出一個NullPointerException時,纔會進行詳細的消息計算,如果我們在Java代碼中顯示拋出異常,則不會執行計算。原因是因爲:在這些情況下,很可能已經在異常構造函數中傳遞了一條有意義的消息。

其次,**JEP 358 ** 懶漢式地計算消息,這意味着只有當我們打印異常消息時才調用增強的NullPointerException,而不是當異常發生時就調用。因此,對於通常的JVM流程不應該有任何性能影響,在那裏我們可以捕獲並重新拋出異常,因爲咱並不會只想打印異常消息。

最後,詳細的異常消息可能包含源代碼中的局部變量名。因此,我們可以認爲這是一個潛在的安全風險。但是,只有在運行使用激活的-g標記編譯的代碼時,纔會發生這種情況,該標記會生成調試信息並將其添加到類文件中。請考慮一個簡單的示例,我們已編譯該示例以包含以下附加調試信息:

Employee employee = null;  
employee.getName();  

當執行以上代碼時,異常信息中會打印本地變量名稱:

"com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName()"  
because "employee" is null  

相反,在沒有額外調試信息的情況下,JVM 只提供它在詳細消息中所知道的變量:

Cannot invoke  
  "com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName()"  
because "<local1>" is null  

JVM 打印編譯器分配的變量索引,而不是本地變量名(employee)。

關於NullPointerException的處理到這裏就結束了,通過Java14增強的NullPointerException,我們可以很快速的定位代碼問題的原因所在,更快的調試代碼,節約時間,提高效率。

已經安裝了Java14的朋友可以試試看哦~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章