• Post Reply Bookmark Topic Watch Topic
  • New Topic

on null pointer exception  RSS feed

 
christine clarin
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi what do you suggest i do with this problem you see, i have:

class A {
int atom;

A (A something) {}

//compares the atoms of A arg1, A arg2
boolean equalTo (A arg1, A arg2){

if (arg1 == null && arg2 == null)
return true;
else {
if (arg1.atom == arg2.atom)
return true;
else
return false;
}
}
}

then I use A from somewhere else, for example in a method with recursion. and because of this, there is a line in my code which compares two null A objects:

if (arg1.equalTo (arg1, new A (null))) //where arg1 and arg2 both null

once it gets to this if condition, i get a null pointer exception. i tried catching the exception in class A inside equalTo method but it still happens. Also I won't be able to put a try catch block in the recursive method because as of now, my professor says I can't. so what do you think should i do? do i have to change something in my equalTo method or do I have to do anything inside my constructor?
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Change this line



to this line


 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jayesh Lalwani:
Change this line



to this line



This seems like a poor solution because if either argument is null, the method will return true. In otherwords, null is "equal to" anything.


Another solution is to add more if statements before you access the member field:

Note that you need to check arguments for null before you compare them. This also begs the question "Are two null references really equal? Or *should* they cause an error?" Typically null values are caused by a problem in your code. So doing this check inside the method will silence an error message when there really is a problem. It would be a lot better to check the parameters before you even call the method.

With that said, I have a question about your design: Why does equalTo() take two arguments? Since it is a member method, it already takes an implict argument that refers to the current object. In fact, Java already provides a mechanism for comparing two Objects with the equals() method. If you override this, your class will be a lot more versatile. It will will also reduce the amount of checks you have to do for null references. For example, you could write a method like this:

You can modify this to check for a null parameter if you want. Notice that only one parameter needs to be checked rather than both.

[ October 09, 2005: Message edited by: Layne Lund ]
[ October 09, 2005: Message edited by: Layne Lund ]
 
Kenneth Albertson
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is nothing wrong with the logic of the tests. This is where the problem occurs:Question: How can you expect to call a method on arg1 when arg1 is null? Answer: It would work if equalTo was a static method. Then either of the following statements will work, although the second is preferred, because it indicates that the method is static.
BTW, as I come from a database background, I agree with Layne that treating two null values as being equal is a rather questionable practice, but that is another issue.
[ October 10, 2005: Message edited by: Kym Thompson ]
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kym Thompson:
There is nothing wrong with the logic of the tests. This is where the problem occurs:Question: How can you expect to call a method on arg1 when arg1 is null? Answer: It would work if equalTo was a static method. Then either of the following statements will work, although the second is preferred, because it indicates that the method is static.
BTW, as I come from a database background, I agree with Layne that treating two null values as being equal is a rather questionable practice, but that is another issue.

[ October 10, 2005: Message edited by: Kym Thompson ]


I don't know about treating two null values as equal. My comment was based on another suggestion that would make null equal to any non-null reference. In my opinion, that is just asking for problems.

Layne
 
Akshay Kiran
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kym Thompson:
There is nothing wrong with the logic of the tests. This is where the problem occurs:Question: How can you expect to call a method on arg1 when arg1 is null? Answer: It would work if equalTo was a static method. Then either of the following statements will work, although the second is preferred, because it indicates that the method is static.
BTW, as I come from a database background, I agree with Layne that treating two null values as being equal is a rather questionable practice, but that is another issue.

[ October 10, 2005: Message edited by: Kym Thompson ]


I couldn't agree more. He has answered all your problems Chri-
Firstly if you need to pass both the objects to be compared, it makes no sense to call the method on a reference,
make it a static boolean equalTo(A arg1, A arg2)
and secondly, it will solve your null pointer exception because you will never be need to call that method on a null reference.
So, when you need to do your comparison,
just say A.equalTo(arg1, arg2);
that should just do the job!
and thanks to Kym
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this situation I usually look hard for other alternatives and dont give up until I find one. In the meantime I do this
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!