Do not use the
null value in any instance where an object is required, including the following cases:
- Calling the instance method of a null object
- Accessing or modifying the field of a null object
- Taking the length of
nullas if it were an array
- Accessing or modifying the elements of
nullas if it were an array
nullas if it were a
null in cases where an object is required results in a
NullPointerException being thrown, which interrupts execution of the program or thread. Code conforming to this coding standard will consequently terminate because ERR08-J. Do not catch NullPointerException or any of its ancestors requires that
NullPointerException is not caught.
Noncompliant Code Example
This noncompliant example shows a bug in Tomcat version 4.1.24, initially discovered by Reasoning [Reasoning 2003]. The
cardinality() method was designed to return the number of occurrences of object
obj in collection
col. One valid use of the
cardinality() method is to determine how many objects in the collection are null. However, because membership in the collection is checked using the expression
obj.equals(elt), a null pointer dereference is guaranteed whenever
obj is null and
elt is not null.
This compliant solution eliminates the null pointer dereference by adding an explicit check:
Noncompliant Code Example
This noncompliant code example defines an
() method that returns true if the specified
String argument is a valid name (two capitalized words separated by one or more spaces):
() is noncompliant because it may be called with a null argument, resulting in a null pointer dereference.
Compliant Solution (Wrapped Method)
This compliant solution includes the same
isProperName() method implementation as the previous noncompliant example, but it is now a private method with only one caller in its containing class.
The calling method,
testString(), guarantees that
() is always called with a valid string reference. As a result, the class conforms with this rule even though a public
isProperName() method would not. Guarantees of this sort can be used to eliminate null pointer dereferences.
Compliant Solution (Optional Type)
This compliant solution uses an
Optional String instead of a
String object that may be null. The
Optional class (
java.util.Optional [API 2014]) was introduced in Java 8 and can be used to mitigate against null pointer dereferences.
EXP01-J-EX0: A method may dereference an object-typed parameter without guarantee that it is a valid object reference provided that the method documents that it (potentially) throws a
NullPointerException, either via the
throws clause of the method or in the method comments. However, this exception should be relied on sparingly.
Dereferencing a null pointer can lead to a denial of service. In multithreaded programs, null pointer dereferences can violate cache coherency policies and can cause resource leaks.
Null pointer dereferences can happen in path-dependent ways. Limitations of automatic detection tools can require manual inspection of code [Hovemeyer 2007] to detect instances of null pointer dereferences. Annotations for method parameters that must be non-null can reduce the need for manual inspection by assisting automated null pointer dereference detection; use of these annotations is strongly encouraged.
|The Checker Framework|
Null pointer errors (see Chapter 3)
|Null pointer dereference|
Null pointer dereference in method on exception path
Method does not check for null argument
Method with Boolean return type returns explicit null
Clone method may return null
close() invoked on a value that is always null
Dereference of the result of readLine() without nullcheck
equals() method does not check for null argument
Null value is guaranteed to be dereferenced
Value is null and guaranteed to be dereferenced on exception path
Immediate dereference of the result of readLine()
Load of known null value
Non-null field is not initialized
Method call passes null to a non-null parameter
Method may return null, but is declared @Nonnull
Possible null pointer dereference due to return value of called method
Possible null pointer dereference in method on exception path
Possible null pointer dereference on branch that might be infeasible
Possible null pointer dereference
Method call passes null for non-null parameter (deref)
Non-virtual method call passes null for non-null parameter
Method call passes null for non-null parameter (deref all)
Parameter must be non-null but is marked as nullable
Store of null value into field annotated @Nonnull
Read of unwritten field
Read of unwritten public or protected field
Nullcheck of value previously dereferenced
toString method may return null
|Null pointers should not be dereferenced|
"toString()" and "clone()" methods should not return null
Null should not be returned from a "Boolean" method
"@NonNull" values should not be set to null
Java Web Start applications and applets particular to JDK version 1.6, prior to update 4, were affected by a bug that had some noteworthy security consequences. In some isolated cases, the application or applet's attempt to establish an HTTPS connection with a server generated a
NullPointerException [SDN 2008]. The resulting failure to establish a secure HTTPS connection with the server caused a denial of service. Clients were temporarily forced to use an insecure HTTP channel for data exchange.
Null Pointer Dereference [XYH]
CWE-476, NULL Pointer Dereference
Android Implementation Details
Android applications are more sensitive to
NullPointerException because of the constraint of the limited mobile device memory. Static members or members of an Activity may become null when memory runs out.
|[API 2014]||Class |
"Defect ID 00-0001"
EXP01-J. Never dereference null pointers LiveLesson
|[Urma 2014]||Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!|