引言

最近新出的Java14，相信大家有所耳聞，面對NullPointerException，Java14有哪些更好的處理方式呢？

1、傳統(tǒng)的NullPointerException

在編碼過程中，經常會用到鏈式的調用方式來寫代碼，方便清晰，但是一旦出現NullPointerException，就頭大了。因為很難知道異常在什么時候發(fā)生。舉個例子：

String city = employe.getDetailInfo().getAddress().getCity();

在鏈式調用過程中，如果 employee，getDetailInfo()，或者getAddress()為空，JVM就會拋出NullPointerExeption，那么導致異常的根本原因是什么？如果不使用調試器，我們很難確認哪個變量為空。而JVM也只會打印導致異常的方法、文件名和行號。

2、增強型 NullPointerException

SAP在2006年為商業(yè)JVM實現了增強型的NullPointerException。2019年，被提議作為一個OpenJDK社區(qū)的增強。本質上JEP 358通過描述某個變量是"null"來提高JVM生成"NullPointerException"的可讀性。通過在方法、文件名和行號旁邊描述為null的變量，帶來一個詳細的NullPointerException消息。通過分析程序的字節(jié)碼指令來工作，因此能夠準確的定位到哪個變量或者表達式為null。

在Java14中，默認是關閉詳細的異常消息的。

要啟用，需要配置：

-xx:+showCodeDeatilsInExceptionMessages

2.1 詳細的異常信息考慮在激活showCodeDeatilsInExceptionMessages標志的情況下再次運行代碼，從附加信息中，可以看到具體的空指針的類，來節(jié)省我們調試所用的時間。

JVM有兩部分組成詳細的異常信息，第一部分表示失敗的操作，是引用為null的結果，第二部分標識了null引用的原因

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

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

3 技術方面

只有當JVM本身拋出"NullPointerException"時，才會進行詳細的消息計劃，如果我們在代碼中顯示拋出異常，則不會執(zhí)行計算。原因：在這些情況下，很可能已經在異常構造函數中傳遞了一條有意義的消息。

其次，JEP 358懶漢式的計算消息，這意味著只有當我們打印異常消息的時候，才調用增強的NullPointerException，而不是當異常發(fā)生時就調用。因此對于通常的JVM流程不應該有任何性能影響。

最后，詳細的異常信息可能包含源代碼中的局部變量名。因此我們認為這是一個潛在的安全風險。但是只有運行使用激活的-G標記編譯的代碼時，才會發(fā)生這樣的情況。

Employee employee = null;
employee.getName();

執(zhí)行以上代碼時，異常信息中會打印本地變量名稱：

"com.xxx.xxx.xxx$Employee.getName()"
because "employee" is null

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

Cannot invoke
 "com.xxx.xxx.xxx$Employee.getName()"
because "<locall>" is null

JVM打印編譯器分配的變量索引，而不是本地變量名（employee）

通過Java14增強型的NullPointerException，我們可以很快定位出代碼問題所在，更快的調試代碼，提高效率。

以上就是Java14對于NullPointerException的新處理方式示例解析的詳細內容，更多關于Java NullPointerException的資料請關注腳本之家其它相關文章！

最新評論