What are Null Pointer Exceptions (java.lang.NullPointerException
) and what causes them?
What methods/tools can be used to determine the cause so that you stop the exception from causing the program to terminate prematurely?
0
What are Null Pointer Exceptions (java.lang.NullPointerException
) and what causes them?
What methods/tools can be used to determine the cause so that you stop the exception from causing the program to terminate prematurely?
0
目录
You can now choose to sort by Trending, which boosts votes that have happened recently, helping to surface more up-to-date answers.
Trending is based off of the highest score sort and falls back to it if no posts are trending.
When you declare a reference variable (i.e., an object), you are really creating a pointer to an object. Consider the following code where you declare a variable of primitive type int
:
int x;
x = 10;
In this example, the variable x
is an int
and Java will initialize it to 0
for you. When you assign the value of 10
on the second line, your value of 10
is written into the memory location referred to by x
.
But, when you try to declare a reference type, something different happens. Take the following code:
Integer num;
num = new Integer(10);
The first line declares a variable named num
, but it does not actually contain a primitive value yet. Instead, it contains a pointer (because the type is Integer
which is a reference type). Since you have not yet said what to point to, Java sets it to null
, which means "I am pointing to nothing".
In the second line, the new
keyword is used to instantiate (or create) an object of type Integer
, and the pointer variable num
is assigned to that Integer
object.
The NullPointerException
(NPE) occurs when you declare a variable but did not create an object and assign it to the variable before trying to use the contents of the variable (called dereferencing). So you are pointing to something that does not actually exist.
Dereferencing usually happens when using .
to access a method or field, or using [
to index an array.
If you attempt to dereference num
before creating the object you get a NullPointerException
. In the most trivial cases, the compiler will catch the problem and let you know that "num may not have been initialized
," but sometimes you may write code that does not directly create the object.
For instance, you may have a method as follows:
public void doSomething(SomeObject obj) {
// Do something to obj, assumes obj is not null
obj.myMethod();
}
In which case, you are not creating the object obj
, but rather assuming that it was created before the doSomething()
method was called. Note, it is possible to call the method like this:
doSomething(null);
In which case, obj
is null
, and the statement obj.myMethod()
will throw a NullPointerException
.
If the method is intended to do something to the passed-in object as the above method does, it is appropriate to throw the NullPointerException
because it’s a programmer error and the programmer will need that information for debugging purposes.
In addition to NullPointerException
s thrown as a result of the method’s logic, you can also check the method arguments for null
values and throw NPEs explicitly by adding something like the following near the beginning of a method:
// Throws an NPE with a custom error message if obj is null
Objects.requireNonNull(obj, "obj must not be null");
Note that it’s helpful to say in your error message clearly which object cannot be null
. The advantage of validating this is that 1) you can return your own clearer error messages and 2) for the rest of the method you know that unless obj
is reassigned, it is not null and can be dereferenced safely.
Alternatively, there may be cases where the purpose of the method is not solely to operate on the passed in object, and therefore a null parameter may be acceptable. In this case, you would need to check for a null parameter and behave differently. You should also explain this in the documentation. For example, doSomething()
could be written as:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj == null) {
// Do something
} else {
// Do something else
}
}
Finally, How to pinpoint the exception & cause using Stack Trace
What methods/tools can be used to determine the cause so that you stop
the exception from causing the program to terminate prematurely?
Sonar with find bugs can detect NPE.
Can sonar catch null pointer exceptions caused by JVM Dynamically
Now Java 14 has added a new language feature to show the root cause of NullPointerException. This language feature has been part of SAP commercial JVM since 2006.
In Java 14, the following is a sample NullPointerException Exception message:
in thread "main" java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because "list" is null
24
"The best way to avoid this type of exception is to always check for null when you did not create the object yourself." If the caller passes null, but null is not a valid argument for the method, then it's correct to throw the exception back at the caller because it's the caller's fault. Silently ignoring invalid input and doing nothing in the method is extremely poor advice because it hides the problem.
Jul 29, 2014 at 13:32
I would add a remark about this post explaining that even assignments to primitives can cause NPEs when using autoboxing: int a=b
can throw an NPE if b is an Integer
. There are cases where this is confusing to debug.
Sep 26, 2014 at 19:45
Is it possible to capture NPE thrown by a webapp from the web browser?like will it show in the view page source from the web browser..
Apr 13, 2015 at 14:51
Yes check if the object equals null before you invoke a method on it or try to access a variable it might have. Some times structuring your code can help avoid null pointer exception. eg when checking an input string with a constant string you should start with the constant string like here: if ("SomeString".equals(inputString)) {} //even if inputString is null no exception is thrown. So there are a bunch of things that you can do to try to be safe.
Nov 11, 2015 at 4:39
An additional way of avoiding NullPointerException
problems in your code is to use @Nullable
and @NotNull
annotations. The following answer has more information on this. Although this answer is specificially about the IntelliJ IDE, it is also applicable to other tools as is apparanet from teh comments. (BTW I am not allowed to edit this answer directly, perhaps the author can add it?)
Jan 3, 2016 at 18:17
NullPointerException
s are exceptions that occur when you try to use a reference that points to no location in memory (null) as though it were referencing an object. Calling a method on a null reference or trying to access a field of a null reference will trigger a NullPointerException
. These are the most common, but other ways are listed on the NullPointerException
javadoc page.
Probably the quickest example code I could come up with to illustrate a NullPointerException
would be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
On the first line inside main
, I’m explicitly setting the Object
reference obj
equal to null
. This means I have a reference, but it isn’t pointing to any object. After that, I try to treat the reference as though it points to an object by calling a method on it. This results in a NullPointerException
because there is no code to execute in the location that the reference is pointing.
(This is a technicality, but I think it bears mentioning: A reference that points to null isn’t the same as a C pointer that points to an invalid memory location. A null pointer is literally not pointing anywhere, which is subtly different than pointing to a location that happens to be invalid.)
11
I understood everything you wrote there, but only because I've been coding for a while and know what a 'pointer' and a 'reference' are (and what null is, for that matter). When I try to dive right into explanations like that, my students look at me crosseyed, because there's not enough background.
Feb 20, 2009 at 4:06
A more common way to get a NullPointerException in practice would be forgetting to explicitly initialize a member variable to something other than null
before using it, like this. With local variables, the compiler would catch this error, but in this case it doesn't. Maybe that would make a useful addition to your answer?
Jan 18, 2014 at 9:28
@EJP I think your points are valid, so I've updated the answer to be clearer and to avoid saying 'points to null' where it did.
Jul 6, 2016 at 22:42
@StevePowell I indicated a long time ago that I didn't want my answer to change. Please respect the intent of the original author.
Jul 6, 2016 at 23:07
Sorry, I was "improving the answer" as requested in the top of this stackoverflow item (This question's answers are a collaborative effort: if you see something that can be improved, just edit the answer to improve it!) I disagree that your version is better, IMO @EJB has valid points; but you are quite welcome to keep your answer intact, confusing though it is.
Jul 14, 2016 at 11:19
A good place to start is the JavaDocs. They have this covered:
Thrown when an application attempts to use null in a case where an
object is required. These include:
- Calling the instance method of a null object.
- Accessing or modifying the field of a null object.
- Taking the length of null as if it were an array.
- Accessing or modifying the slots of null as if it were an array.
- Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other
illegal uses of the null object.
It is also the case that if you attempt to use a null reference with synchronized
, that will also throw this exception, per the JLS:
SynchronizedStatement: synchronized ( Expression ) Block
- Otherwise, if the value of the Expression is null, a
NullPointerException
is thrown.
So you have a NullPointerException
. How do you fix it? Let’s take a simple example which throws a NullPointerException
:
public class Printer {
private String name;
public void setName(String name) {
this.name = name;
}
public void print() {
printString(name);
}
private void printString(String s) {
System.out.println(s + " (" + s.length() + ")");
}
public static void main(String[] args) {
Printer printer = new Printer();
printer.print();
}
}
Identify the null values
The first step is identifying exactly which values are causing the exception. For this, we need to do some debugging. It’s important to learn to read a stacktrace. This will show you where the exception was thrown:
Exception in thread "main" java.lang.NullPointerException
at Printer.printString(Printer.java:13)
at Printer.print(Printer.java:9)
at Printer.main(Printer.java:19)
Here, we see that the exception is thrown on line 13 (in the printString
method). Look at the line and check which values are null by
adding logging statements or using a debugger. We find out that s
is null, and calling the length
method on it throws the exception. We can see that the program stops throwing the exception when s.length()
is removed from the method.
Trace where these values come from
Next check where this value comes from. By following the callers of the method, we see that s
is passed in with printString(name)
in the print()
method, and this.name
is null.
Trace where these values should be set
Where is this.name
set? In the setName(String)
method. With some more debugging, we can see that this method isn’t called at all. If the method was called, make sure to check the order that these methods are called, and the set method isn’t called after the print method.
This is enough to give us a solution: add a call to printer.setName()
before calling printer.print()
.
The variable can have a default value (and setName
can prevent it being set to null):
private String name = "";
Either the print
or printString
method can check for null, for example:
printString((name == null) ? "" : name);
Or you can design the class so that name
always has a non-null value:
public class Printer {
private final String name;
public Printer(String name) {
this.name = Objects.requireNonNull(name);
}
public void print() {
printString(name);
}
private void printString(String s) {
System.out.println(s + " (" + s.length() + ")");
}
public static void main(String[] args) {
Printer printer = new Printer("123");
printer.print();
}
}
See also:
If you tried to debug the problem and still don’t have a solution, you can post a question for more help, but make sure to include what you’ve tried so far. At a minimum, include the stacktrace in the question, and mark the important line numbers in the code. Also, try simplifying the code first (see SSCCE).
3
@RuchirBaronia A debugger allows you to step through a program line by line to see which methods are called and how variables are changed. IDEs should have some tools to do this. See vogella.com/tutorials/EclipseDebugging/article.html for example.
Dec 10, 2015 at 10:22
@RuchirBaronia You set breakpoints on the methods around any NullPointerExceptions as seen in the stacktrace, and check the values of variables against what you expect them to be. If you know a variable is null when it shouldn't be, then you can set breakpoints around any code that changes the value. There are also conditional breakpoints you can use which will tell you when a value changes.
Dec 10, 2015 at 11:33
i suggest also static analysis tools, like FINDBUGS en.m.wikipedia.org/wiki/FindBugs
Jun 30, 2017 at 12:32
NullPointerException
(NPE)?As you should know, Java types are divided into primitive types (boolean
, int
, etc.) and reference types. Reference types in Java allow you to use the special value null
which is the Java way of saying "no object".
A NullPointerException
is thrown at runtime whenever your program attempts to use a null
as if it was a real reference. For example, if you write this:
public class Test {
public static void main(String[] args) {
String foo = null;
int length = foo.length(); // HERE
}
}
the statement labeled "HERE" is going to attempt to run the length()
method on a null
reference, and this will throw a NullPointerException
.
There are many ways that you could use a null
value that will result in a NullPointerException
. In fact, the only things that you can do with a null
without causing an NPE are:
==
or !=
operators, or instanceof
.Suppose that I compile and run the program above:
$ javac Test.java
$ java Test
Exception in thread "main" java.lang.NullPointerException
at Test.main(Test.java:4)
$
First observation: the compilation succeeds! The problem in the program is NOT a compilation error. It is a runtime error. (Some IDEs may warn your program will always throw an exception … but the standard javac
compiler doesn’t.)
Second observation: when I run the program, it outputs two lines of "gobbledy-gook". WRONG!! That’s not gobbledy-gook. It is a stacktrace … and it provides vital information that will help you track down the error in your code if you take the time to read it carefully.
So let’s look at what it says:
Exception in thread "main" java.lang.NullPointerException
The first line of the stack trace tells you a number of things:
java.lang.NullPointerException
.NullPointerException
is unusual in this respect, because it rarely has an error message.The second line is the most important one in diagnosing an NPE.
at Test.main(Test.java:4)
This tells us a number of things:
main
method of the Test
class.If you count the lines in the file above, line 4 is the one that I labeled with the "HERE" comment.
Note that in a more complicated example, there will be lots of lines in the NPE stack trace. But you can be sure that the second line (the first "at" line) will tell you where the NPE was thrown1.
In short, the stack trace will tell us unambiguously which statement of the program has thrown the NPE.
See also: What is a stack trace, and how can I use it to debug my application errors?
1 – Not quite true. There are things called nested exceptions…
This is the hard part. The short answer is to apply logical inference to the evidence provided by the stack trace, the source code, and the relevant API documentation.
Let’s illustrate with the simple example (above) first. We start by looking at the line that the stack trace has told us is where the NPE happened:
int length = foo.length(); // HERE
How can that throw an NPE?
In fact, there is only one way: it can only happen if foo
has the value null
. We then try to run the length()
method on null
and… BANG!
But (I hear you say) what if the NPE was thrown inside the length()
method call?
Well, if that happened, the stack trace would look different. The first "at" line would say that the exception was thrown in some line in the java.lang.String
class and line 4 of Test.java
would be the second "at" line.
So where did that null
come from? In this case, it is obvious, and it is obvious what we need to do to fix it. (Assign a non-null value to foo
.)
OK, so let’s try a slightly more tricky example. This will require some logical deduction.
public class Test {
private static String[] foo = new String[2];
private static int test(String[] bar, int pos) {
return bar[pos].length();
}
public static void main(String[] args) {
int length = test(foo, 1);
}
}
$ javac Test.java
$ java Test
Exception in thread "main" java.lang.NullPointerException
at Test.test(Test.java:6)
at Test.main(Test.java:10)
$
So now we have two "at" lines. The first one is for this line:
return args[pos].length();
and the second one is for this line:
int length = test(foo, 1);
Looking at the first line, how could that throw an NPE? There are two ways:
bar
is null
then bar[pos]
will throw an NPE.bar[pos]
is null
then calling length()
on it will throw an NPE.Next, we need to figure out which of those scenarios explains what is actually happening. We will start by exploring the first one:
Where does bar
come from? It is a parameter to the test
method call, and if we look at how test
was called, we can see that it comes from the foo
static variable. In addition, we can see clearly that we initialized foo
to a non-null value. That is sufficient to tentatively dismiss this explanation. (In theory, something else could change foo
to null
… but that is not happening here.)
So what about our second scenario? Well, we can see that pos
is 1
, so that means that foo[1]
must be null
. Is this possible?
Indeed it is! And that is the problem. When we initialize like this:
private static String[] foo = new String[2];
we allocate a String[]
with two elements that are initialized to null
. After that, we have not changed the contents of foo
… so foo[1]
will still be null
.
On Android, tracking down the immediate cause of an NPE is a bit simpler. The exception message will typically tell you the (compile time) type of the null reference you are using and the method you were attempting to call when the NPE was thrown. This simplifies the process of pinpointing the immediate cause.
But on the flipside, Android has some common platform-specific causes for NPEs. A very common is when getViewById
unexpectedly returns a null
. My advice would be to search for Q&As about the cause of the unexpected null
return value.
It’s like you are trying to access an object which is null
. Consider below example:
TypeA objA;
At this time you have just declared this object but not initialized or instantiated. And whenever you try to access any property or method in it, it will throw NullPointerException
which makes sense.
See this below example as well:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
1
If we give System.out.println(a.length()); // NullPointerException will be thrown, to skip this we can handle with try catch block. thank you
Feb 7, 2019 at 7:25
A null pointer exception is thrown when an application attempts to use null in a case where an object is required. These include:
null
object.null
object.null
as if it were an array.null
as if it were an array.null
as if it were a Throwable value.Applications should throw instances of this class to indicate other illegal uses of the null
object.
Reference: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
3
Keep it simple, I like this answer, add this if you consider correct – Access to uninitialized attribute of an object
Mar 23, 2016 at 13:06
@Emiliano – simply accessing an initialized attribute does not cause an NPE. It is what you >>do<< with the uninitialized attribute value that causes the NPE.
May 19, 2016 at 6:57
If you want more cases: 1) using a null
as the target of a synchronized
block, 2) using a null
as the target of a switch
, and unboxing null
.
Oct 23, 2017 at 10:16
A null
pointer is one that points to nowhere. When you dereference a pointer p
, you say “give me the data at the location stored in “p”. When p
is a null
pointer, the location stored in p
is nowhere
, you’re saying “give me the data at the location ‘nowhere'”. Obviously, it can’t do this, so it throws a null pointer exception
.
In general, it’s because something hasn’t been initialized properly.
1
"A NULL pointer is one that points to nowhere" I disagree. Null pointers don't point to nowhere, they point to null values.
Sep 8, 2018 at 22:46
A lot of explanations are already present to explain how it happens and how to fix it, but you should also follow best practices to avoid NullPointerException
s at all.
See also:
A good list of best practices
I would add, very important, make a good use of the final
modifier.
Using the "final" modifier whenever applicable in Java
Summary:
final
modifier to enforce good initialization.@NotNull
and @Nullable
if("knownObject".equals(unknownObject)
valueOf()
over toString()
.StringUtils
methods StringUtils.isEmpty(null)
.10
In j2ee projects,Nullpointer exception is very common.Some cases reference variables got null values.So You should check the variable initialization properly.And during conditional statement you should always check that flag or reference contains null or not like:- if(flag!=0) { ur code that uses flag }
Apr 17, 2015 at 12:58
It is worth mentioning that some IDEs (e.g. Eclipse) offer automatic nullity analisys based on customizable annotations (e.g. @Nullable
as listed above) and warn about potential errors. It is also possible to infer and generate such annotations (e.g. IntelliJ can do that) based on existing code structure.
Mar 5, 2016 at 10:34
First thing should do is before using a nullable object, you should check whether is it null, using if (obj==null)
.If it is null then you should write code to handle that also.
Feb 17, 2017 at 6:52
IMO, it is preferable to avoid returning null objects in methods when possible and use annotation when null input parameters are not allowed in order to, by contract, reduce the amount of ´if (obj==null)´ in the code and improve the code readability.
Feb 27, 2017 at 9:43
Read this … before you accept these "best practices" as truth: satisfice.com/blog/archives/27
May 21, 2017 at 7:52
A null pointer exception is an indicator that you are using an object without initializing it.
For example, below is a student class which will use it in our code.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
The below code gives you a null pointer exception.
public class School {
Student student;
public School() {
try {
student.getId();
}
catch(Exception e) {
System.out.println("Null pointer exception");
}
}
}
Because you are using student
, but you forgot to initialize it like in the
correct code shown below:
public class School {
Student student;
public School() {
try {
student = new Student();
student.setId(12);
student.getId();
}
catch(Exception e) {
System.out.println("Null pointer exception");
}
}
}
2
While this is a nice example, may I ask what it adds to the question that isn't already covered by all the other answers?
Sep 24, 2013 at 6:20
It is simply inappropriate to use the word "uninitialized" here. The example you shown is in fact "initialized", and it is initialized with null. For uninitialized variables, compiler will complain to you.
Sep 24, 2013 at 6:32
In Java, everything (excluding primitive types) is in the form of a class.
If you want to use any object then you have two phases:
Example:
Object object;
object = new Object();
Same for the array concept:
Item item[] = new Item[5];
item[0] = new Item();
If you are not giving the initialization section then the NullPointerException
arise.
2
A NullPointerException often occurs when calling method of an instance.For example, if you declare a reference but does not make it point to any instance, NullPointerException will happen when you call its method. such as: YourClass ref = null; // or ref = anotherRef; // but anotherRef has not pointed any instance ref.someMethod(); // it will throw NullPointerException. Generally fix it in this way: Before the method is called, determine whether the reference is null. such as: if (yourRef != null) { yourRef.someMethod(); }
Jul 28, 2017 at 10:25
Or use exception capture: such as: try { yourRef.someMethod(); } catch (NullPointerException e) { // TODO }
Jul 28, 2017 at 10:25
In Java all the variables you declare are actually “references” to the objects (or primitives) and not the objects themselves.
When you attempt to execute one object method, the reference asks the living object to execute that method. But if the reference is referencing NULL (nothing, zero, void, nada) then there is no way the method gets executed. Then the runtime let you know this by throwing a NullPointerException.
Your reference is “pointing” to null, thus “Null -> Pointer”.
The object lives in the VM memory space and the only way to access it is using this
references. Take this example:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
And on another place in your code:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
This an important thing to know – when there are no more references to an object (in the example above when reference
and otherReference
both point to null) then the object is “unreachable”. There is no way we can work with it, so this object is ready to be garbage collected, and at some point, the VM will free the memory used by this object and will allocate another.
Another occurrence of a NullPointerException
occurs when one declares an object array, then immediately tries to dereference elements inside of it.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
This particular NPE can be avoided if the comparison order is reversed; namely, use .equals
on a guaranteed non-null object.
All elements inside of an array are initialized to their common initial value; for any type of object array, that means that all elements are null
.
You must initialize the elements in the array before accessing or dereferencing them.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
4
operation on uninitialized object at instance level(not the class level) will lead to NullPointerException. operation need to be instance specific. if operation is at class level, saying calling a static method on uninitialized object then it will not throw NullPointerException exception. Even primitive wrapper class objects throws NullPointerException.
Jul 8, 2016 at 15:20
1. NullPointerException is a RuntimeException, that means will appear when your program is running, you will not at compilation time.! :(, but most of the IDE help you to discover this. 2. Minimize the use of the keyword 'null' in assignment statements. 🙂 Reference url:
Dec 4, 2017 at 5:49
@tomj0101 I'm thoroughly unclear as to why you made that comment… But to your second point, a pattern before Optional
was to return null. The keyword is fine. Knowing how to guard against it is critical. This offers one common occurrence of it and ways to mitigate it.
Dec 4, 2017 at 5:54
本文来自转载,原文链接:
|