- Collections: remove(int) vs remove(Object)
With two different versions of the remove method on a Collection you can unintentional call the wrong one. For example remove(char c); will cast the char to an int and try to remove an object at 99 (the ascii code for 'c'). This leads to unpredictable results or an arrayIndexoutofbounds error depending on the size of the array.
The solution is to use non-primitive types for the object. So instead of remove(char) do remove(Character).
- Boolean Comparison: && and ||
This problem can lead to some of the more confusing errors. The root cause is that when java the value for the left side that will set the result regardless of the second side, it won't even evaluate the second side. This becomes a problem when the second side does something other than return the value (like many remove functions that return true or false depending on if it actually removes anything).
The solution here is to make sure the second is a variable. If both sides are functions then assign one of them to a boolean variable before comparing. Of course completely avoiding this situation in the first case would also help : )
- Integer Division When you type 9/4 into the program you expect 2.25 but instead you only get 2. If both numbers in the operation are integers, the answer is cast to an integer. This gotcha can be found fairly easily if it is a simple equation. The trouble appears when you get really complex equations, imagine trying to pick that out of a quartic equation .
This solution to the problem is to have one of the operands be a double. If the value is assigned somewhere else and you are using variables (int1/int2) you can add '(double)' in front of one of the numbers. If the values are defined in the equation (2/5), converting to a double is a simple matter of adding a decimal point '2./5'.
- equality - == vs .equals()
As beginners we are taught that == means equality. In most programs beginners wrote, this worked fine. 2==2 would come out true and 2 == 1 would come out false, that was all we needed. Then you start learning about object oriented programs and create your own classes. Suddenly == doesn't work like expected anymore, even though the objects are the same in all ways it comes up false. The reason is that == doesn't test for equality, it tests to see if the object takes up the same space in memory ( other languages use 'is' which I think is more obvious). Because primitives are so simple the jvm can safely store two references to equal primitives in the same memory creating the illusion that == checks for equality. == feels so natural that even after you realize exactly what it does it can slip up and catch you when you get careless.
The .equals() method is java's solution. The .equals() <b>should</b> be designed to test for that ( though the reliability depends on the developer who made the class). When you create your own class you have the option of overriding the .equals() method and designing it to get whether or not the object is equal based on what you decide.
Page 1 of 1
Java Gotchas You never seem em coming!
Posted 08 October 2009 - 03:59 PM
Gotchas are bits of code that do something completely different from what you expected. These bits of code are often hard to catch and identify leaving you debugging for hours on end with no luck. The best way to keep yourself safe is to know them ahead of time. Here are some of the ones I have encountered before.
Replies To: Java Gotchas
Posted 12 December 2013 - 03:10 AM
[*]Boolean Comparison: && and ||
In case people want more information on this subject, it's proper term is Short-circuit evaulation.
Thanks for the nice summary!
Page 1 of 1