Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what is the way Java14 handles NullPointerException". In the operation of actual cases, many people will encounter this dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Traditional NullPointerException

In the process of coding, we often use chained calls to write code, which is very convenient and clear to write, but once NullPointerException appears, it will be a big head, because it is difficult to know when the exception began to occur.

To take a simple example, such as the following code, to find the domicile location of an employee in the company, we call the

String city = employee.getDetailInfos (). GetRegistryAddress (). GetCity ()

During a chain call, JVM throws a NullPointerException if employee, getDetailInfos (), or getRegistryAddress () is empty.

So what is the root cause of the exception? If you do not use the debugger, it is difficult to determine which variable is empty. Also, JVM only prints the method, file name, and line number that caused the exception, that's all. So next, I'll show you how Java 14 solves this problem with JEP 358.

two。 Enhanced NullPointerException

SAP implemented an enhanced NullPointerException for its commercial JVM in 2006. In February 2019, it was proposed as an enhancement to the OpenJDK community, and soon after, it became a JEP. As a result, the feature was completed in October 2019 and launched in JDK 14.

In essence, JEP 358 aims to improve the readability of "NullPointerException" generated by JVM by describing a variable as "null". JEP 358 brings a detailed NullPointerException message with variables described as null next to the method, file name, and line number. It works by analyzing the bytecode instructions of the program. Therefore, it can determine exactly which variable or expression is null. Most importantly, detailed exception messages are turned off by default in JDK 14. To enable it, we need to use the command line option:

-XX:+ShowCodeDetailsInExceptionMessages

2.1 detailed exception information

Consider running the code again with the ShowCodeDetailsInExceptionMessages flag activated:

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)

This time, from the additional information, we know that the missing registered address of the employee's personal details caused our exception. The information gained from this enhancement can save us the time we spend debugging.

The JVM consists of two parts that make up a detailed exception message. The first part represents the failed operation, which is the result of the reference to null, while the second part identifies the reason for the null reference:

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

To generate exception messages, JEP 358 reconstructs parts of the source code that push null references onto the Operand stack.

3. Technical aspect

Now that we have a good understanding of how to use enhanced NullPointerExceptions to identify null references, let's take a look at some of its technical aspects.

First, detailed message calculations are performed only when the JVM itself throws a NullPointerException, and if we explicitly throw an exception in the Java code, the calculation is not performed. The reason is that in these cases, a meaningful message has probably been passed in the exception constructor.

Second, * * JEP 358 * * calculates messages in a lazy manner, which means that the enhanced NullPointerException is called only when we print an exception message, not when an exception occurs. Therefore, there should be no performance impact on the normal JVM process, where we can catch and re-throw exceptions because we don't just want to print exception messages.

Finally, the detailed exception message may contain the local variable name in the source code. Therefore, we can think of this as a potential security risk. However, this occurs only when running code compiled with the active-g flag, which generates debugging information and adds it to the class file. Consider a simple example that we have compiled to include the following additional debugging information:

Employee employee = null

Employee.getName ()

When the above code is executed, the local variable name is printed in the exception information:

"com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName ()"

Because "employee" is null

Instead, in the absence of additional debugging information, JVM provides only the variables it knows in the detailed message:

Cannot invoke

"com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName ()"

Because "" is null

JVM prints the variable index assigned by the compiler instead of the local variable name (employee).

The processing of NullPointerException ends here. With Java14 enhanced NullPointerException, we can quickly locate the cause of the code problem, debug the code faster, save time, and improve efficiency.

This is the end of the content of "how Java14 handles NullPointerException". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.