JavaScript is not currently enabled, but is required for full CodeSonar manual search and browse functionality.

If you are viewing this file in your hub's Web GUI, enable JavaScript in your browser: you will also need it for GUI functionality.

If you opened this file directly from disk, your browser may be directly suppressing JavaScript functionality: certain browsers perform this suppression on local files (but not files delivered by web servers) for security reasons.

CodeSonar® 9.2p0 CONFIDENTIAL CodeSecure Inc
Java


JAVA.DEEPNULL.RET.METH : Return Value may be null (Java)

Summary

A method might return null.

This checker looks for program points where, at runtime, a null pointer might be dereferenced and the execution stopped with a NullPointerException. It also looks for calls to library methods where null, or a collection or array containing a null element, might be passed as a parameter in a place where this is not allowed.

Since nullness is undecidable, it is impossible to find all and only the nullness bugs, without any false positive. As a consequence, the analyzer will often issue spurious warnings, where a fake bug is signalled because the analyzer is not clever enough to understand that some value is never actually null. However, the analyzer is currently the only analyzer that does not miss nullness bugs: if there is a real bug, it will be signalled. If the number of false alarms is too high and soundness is not paramount, it is also possible to use the corresponding basic warning class, which is unsound but yields its results much more quickly and with fewer false alarms.

Manually-provided Annotations

In order to reduce the number of false positives, you can instruct the analyzer with nullness annotations, placed in the code that you analyze. Usually, one performs a first nullness analysis and gets many fake warnings (false positives), but most of them have the same origin: a field that the analyzer does not identify as non-null or a method that the analyzer does not identify as always returning a non-null value. Hence, you can use this first analysis to place annotations in your code and then start the analysis again. In particular, the analyzer can be helped by putting the following annotations in the code under analysis:

It is also possible to state that a given expression is non-null at a specific program point. For that, use NullnessAssertions.assertNonNull(expression). Note that the fact that a variable is non-null at a program point does not prevent it from holding null later.

Properties

Class Name Return Value may be null (Java)
Significance reliability
Mnemonic JAVA.DEEPNULL.RET.METH
Categories
CWE CWE:476 NULL Pointer Dereference
CERT-Java CERT-Java:EXP01-J Do not use a null in a case where an object is required
OWASP-2025 OWASP-2025:A10 Mishandling of Exceptional Conditions
Availability Available for Java and Kotlin.
Enabling Checks for this warning class are disabled by default. To enable them, add the following WARNING_FILTER rule to the project configuration file.
WARNING_FILTER += allow class="Return Value may be null (Java)"

Resolution

Check if the value is actually null and modify the program in such a way to be sure that it is never null again. In most cases, a nullness bug is the consequence of a more complex bug, where some field is not always initialized before being used. Try to define as many as possible of your fields as final. Do not use null as a special value returned by a method.

Relevant Configuration File Parameters

The following configuration file parameters affect checks for this warning class.

 

To report problems with this documentation, please visit https://support.codesecure.com/.