Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Exception not being caught  RSS feed

 
kiennjal shah
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have the following code which compiles fine, but doesnt work:


this is actually a problem from one of the JCP prep books. it compiles fine, but everytime I run it, regardless of whatever i put as command line arg, it always prints only: Yummy!!! I like this food

Can anyone suggest as to why this is not working?

Thanks

-Kiennjal
 
Stefan Willi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi kiennjal !

Please pay attention to your comparison of the string Object. You compare the reference of the string literal with the reference of your argument object. that cannot be equal...
To identify, if two strings are equal, use the equal() ore equalIgnoreCase() methods.


Stefan
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"==" operator checks whether the variable food using the same memory address as "peas". Obviously, they are using different memory addresses and thus, the comparsion always return false.

Nick
 
Ravi Kishore
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi kiennjal,

what nicholas and stefan has said is correct. "==" operator always compares the references (addresses) but not the contents pointed by the addresses. So for string comparisions it's advisable to use equals() or equalIgnoreCase() functions.

keep in mind that while comparing a string object aganist a string constant always proceed as follows:

String str = "peas";
if("beans".equals(str))
{
//do something
}
else
{
//do something
}

but if it is done as follows:

if(str.equals("beans"))
{
//do something
}
else
{
//do something
}

a new dummy object is created for the string constant "beans" and then the comparision takes place. which will consume memory unnecessarly.
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ravi Kishore:
a new dummy object is created for the string constant "beans" and then the comparision takes place. which will consume memory unnecessarly.


It shouldn't matter. The "beans" is a string literal; as such, an object is always created. At runtime, there's no difference between a "string object" and a "string literal;" both are instances of java.lang.String. (OK, the string literal is stored in the literal pool...)

The primary reason for placing the string literal first is to avoid NullPointerExceptions.:


could throw a NPE if food were null.


returns false if food were null.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By taking about the handling of NullPointerException for null strings, currently, we try to use an alternative approach.

We used the APIs provided by Jakarta Common, the StringUtils. This package provides lots of functions for string manipulations, like isEmpty(), isBlank(), equals(), etc. And the APIs have been internally handled the null cases, i.e., if x is null, StringUtils.isEmpty(x) returns true instead of throwing the NullPointerException.

Nick
 
kiennjal shah
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all for your help. That was so very silly of me!!!

Joel, thanks for pointing out the effect of placing str before the method: equals.

Have a good one!

-Kiennjal
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!