• Post Reply Bookmark Topic Watch Topic
  • New Topic

java.lang.NullPointerException  RSS feed

 
Aggarwal Arpit
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am facing this issue in my code when I am compiling-java.lang.NullPointerException.
Can anybody has the solution for it?

Thanks in advance for your answers.
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you show us the offending code? Also post the error message exactly as it appears, copied and pasted.
 
Avinash Ga
Ranch Hand
Posts: 78
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
please post your code which is causing the exception. also please mention your intention with your program.

Best Wishes
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're unlikely to be getting a NullPointerException when you compile. That's a runtime error, which occurs because you're doing something to a reference that is null. For instance, calling a method on a null reference.

For example, this would do it:

The first thing you need to do is work out which reference is null. That's usually quite straightforward. The exception will give you a line number, so that narrows it down a lot. It's possible there may be multiple candidates on that line - if it's not obvious which one isn't null then either run it through a debugger or add some print statements to help you find out.

Once you've found the offending reference, you can either check if it's null first (if being null is a valid condition), or fix the place it's initialised (if being null is an error).

Can't say more than that without more details.
 
Avinash Ga
Ranch Hand
Posts: 78
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes matthew, one more thing for the above code, if we do



then you wont get a null pointer. instead the result will be false.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Avinash Ga wrote:yes matthew, one more thing for the above code, if we do



then you wont get a null pointer. instead the result will be false.


True, but it's also less readable, forcing us to invert the natural order of the expression.
 
Rob Spoor
Sheriff
Posts: 21133
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a matter of opinion. I don't mind that way at all, and prefer it to having to first check if str is not null - a check that is performed again within the equals method you're calling (only then for the String literal "str").
 
Avinash Ga
Ranch Hand
Posts: 78
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed Dennis. Thanks Rob.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Spoor wrote:That's a matter of opinion. I don't mind that way at all, and prefer it to having to first check if str is not null - a check that is performed again within the equals method you're calling (only then for the String literal "str").

If null is a condition we care about, then absolutely we need to check for it. It's irrelevant that String.equals checks the argument for null, since it doesn't share its findings with us. If we don't care, then sure throw readability under the bus of expedience. Just don't ask me to debug it.
 
Rob Spoor
Sheriff
Posts: 21133
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The result of str != null && str.equals("str") is 100% the same as "str".equals(str). Both are false of str == null, and both are only true if str contains the characters s, t and r in that order. So you say we should check for null? That's exactly what I'm doing when I put the String literal first, because I know that x.equals(null) should be false for every object x. In the end it's all just a matter of preference, and I prefer short code if possible. If that means you have problems reading my code 'd definitely advise you to stay away from C or PHP code where everything can be evaluated as a boolean; a quick example is a simple implementation of C's strcpy: Yes that looks horrible, but it's quite common to do things like that in those languages.

Shall we agree to disagree on this style and move on? I don't mind a discussion, but like the VI vs Emacs and the Eclipse vs Netbeans discussions, there is no correct answer, only opinions.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:It's irrelevant that String.equals checks the argument for null, since it doesn't share its findings with us.


No, it's not irrelevant, and it does share its findings. From the javadocs for String's equals() method:

The result is true if and only if the argument is not null and is a String object that represents the same sequence of characters as this object.


In other words, String shares with us the fact that someString.equals(null) gives false. So if that matches the logic we need, we can rely on that, and "myLiteral".equals(stringUnderTest) will give us exactly the results we want. (And for what it's worth, I find that just as readable as the other way around, and I use it all the time. On the other hand, I *hate* null == whatever.) Now, of course, if we have a precondition that says that null is not a valid input, then we need to test for that first and throw an appropriate exception.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Dennis Deems wrote:It's irrelevant that String.equals checks the argument for null, since it doesn't share its findings with us.


No, it's not irrelevant, and it does share its findings. From the javadocs for String's equals() method:

The result is true if and only if the argument is not null and is a String object that represents the same sequence of characters as this object.


In other words, String shares with us the fact that someString.equals(null) gives false.


That's not sharing its findings. That's silently returning the value it deems appropriate. False is also given for most non-null values. We have no way of knowing if the argument is null unless we examine it. Perhaps in your enthusiasm to hit the "reply" button you ignored the first sentence in my post:
If null is a condition we care about, then absolutely we need to check for it.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:
Jeff Verdegan wrote:
Dennis Deems wrote:It's irrelevant that String.equals checks the argument for null, since it doesn't share its findings with us.


No, it's not irrelevant, and it does share its findings. From the javadocs for String's equals() method:

The result is true if and only if the argument is not null and is a String object that represents the same sequence of characters as this object.


In other words, String shares with us the fact that someString.equals(null) gives false.


That's not sharing its findings. That's silently returning the value it deems appropriate. False is also given for most non-null values.


But we don't care if it's null or not. Just as we don't care if they're not equal because they're of different lenghts, or because the first character differs or the last or the Nth. We only care whether they are equal or not--by definition, since we're using equals()--and equals() documents that it treats null as false, and that's all the "findings" we need here.

We have no way of knowing if the argument is null unless we examine it.


And as I already said, I was talking about the case where we don't care.

Perhaps in your enthusiasm to hit the "reply" button you ignored the first sentence in my post:
If null is a condition we care about, then absolutely we need to check for it.


Perhaps. Just as in your enthusiasm you seem to have ignored my comments to the effect that I was talking about the case where we don't care if it's null.

Actually, though, I did see that, and didn't so much ignore it as I thought the next part:
It's irrelevant that String.equals checks the argument for null, since it doesn't share its findings with us.
seemed like you were talking in the general case, and not just when we care about null.

And this part:
If we don't care, then sure throw readability under the bus of expedience. Just don't ask me to debug it.
just sounded like you were looking for an argument, so I thought I'd be kind and oblige.

 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!