In the Java language, dealing with null Pointers is often a headache, and if you’re not careful, you could end up with an online Bug that will give you a 3.25 performance review. NullPointerException is a NullPointerException that can be handled by Java14.1. Traditional NullPointerExceptionIn our coding process, we often use the chain call method to write code, which is easy and clear to write, but when NullPointerException occurs, it’s very difficult to know when the exception started. For a simple example, such as the following code, to find the domicile of an employee in the company, we callString city = employee.getDetailInfos().getRegistryAddress().getCity();During a chain call, if employee, getDetailInfos(), or getRegistryAddress() is null, the JVM throws a NullPointerException. What is the root cause of the exception? Without using a debugger, it is difficult to determine which variable is null. Also, the JVM simply prints the method, filename, and line number that caused the exception, and that’s it. Now, I’ll take you through how Java 14 solves this problem with JEP 358.2. Enhanced NullPointerExceptionSAP implemented an enhanced NullPointerException for its commercial JVMS 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, this feature was completed and released in JDK 14 in October 2019. In essence, JEP 358 aims to improve the readability of “NullpointerExceptions” generated by the JVM by describing a variable as “null.” JEP 358 brings a detailed NullPointerException message with variables described as NULL next to the method, filename, 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 informationConsider in the case of activated ShowCodeDetailsInExceptionMessages sign again to run the code: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 loss of the employee’s personal details to the registered address is causing our exception. The information gained from this enhancement can save us time for debugging. The JVM consists of two parts for a detailed exception message. The first section represents the failed operation, which is referenced asnullThe second part identifies the resultsnullReasons cited:Cannot invoke "String.toLowerCase()" because the return value of "getEmailAddress()" is nullTo generate exception messages, JEP 358 reconstructs a portion of the source code that pushes empty references onto the operand stack.3. TechnologyNow that we have a good understanding of how to use the enhanced NullPointerExceptions to identify NULL references, let’s look at some of its technical aspects. First, detailed message calculations are only performed when the JVM itself throws a NullPointerException, and not if we explicitly throw an exception in Our Java code. The reason is this: in these cases, it is likely that a meaningful message has already been passed in the exception constructor. Second, **JEP 358 ** calculates messages lazily, which means that the enhanced NullPointerException is called only when we print an exception message, not when it occurs. Therefore, there should be no performance impact on the normal JVM flow, where we can catch and rethrow exceptions, because we don’t just want to print exception messages. Finally, detailed exception messages may contain local variable names in the source code. Therefore, we can consider this a potential security risk. However, this only happens when you run code compiled with the active -G tag, 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 message:"com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName()" because "employee" is nullInstead, without additional debugging information, the JVM provides only the variables it knows in the verbose message:Cannot invoke "com.developlee.java14.helpfulnullpointerexceptions.HelpfulNullPointerException$Employee.getName()" because "<local1>" is nullThe JVM prints the compiler-assigned variable index instead of the local variable name (EMPLOYEE). This is the end of NullPointerException processing. With Java14 enhanced NullPointerException, we can quickly locate the cause of code problems, debug the code faster, save time and improve efficiency. If you already have Java14 installed, you can try it
Welcome to follow my wechat public account “Code farming breakthrough”, share Python, Java, big data, machine learning, artificial intelligence and other technologies, pay attention to code farming technology improvement, career breakthrough, thinking transition, 200,000 + code farming growth charge first stop, accompany you have a dream to grow together