Thus, we could consider this a potential security risk. As a result, there shouldn't be any performance impact for the usual JVM flows, where we catch and rethrow exceptions, since we don't always print the exception message.įinally, the detailed exception message may include local variable names from our source code. Secondly, JEP 358 calculates the message lazily, meaning only when we print the exception message and not when the exception occurs. The reason behind this is that, in these situations, most probably we already pass a meaningful message in the exception constructor. Technical Aspectsįirstly, a detailed message computation is only done when the JVM itself throws a NullPointerException - the computation won't be performed if we explicitly throw the exception in our Java code.
NULLPOINTEREXCEPTION JAVA NEW FLOWLAYOUT CODE
To build the exception message, JEP 358 recreates the part of the source code that pushed the null reference onto the operand stack. The first part represents the failing operation, a consequence of a reference being null, while the second part identifies the reason for the null reference: Cannot invoke "String.toLowerCase()" because the return value of "getEmailAddress()" is null JVM composes the detailed exception message from two parts. The knowledge gained from this enhancement can save us time during debugging. This time, from the additional information, we know that the missing email address of the employee's personal details causes our exception. ".HelpfulNullPointerException$PersonalDetails.getEmailAddress()" is nullĪt .HelpfulNullPointerException.main(HelpfulNullPointerException.java:10) Let's consider running the code again with the ShowCodeDetailsInExceptionMessages flag activated: Exception in thread "main" :Ĭannot invoke "String.toLowerCase()" because the return value of
0 kommentar(er)
