Now take a second to ask yourself, what is wrong with this? You might write a quick unit test to pass in values like “Is THIS the same” or “This doesn’t equal” and more than likely “Is this the same”. The tests all pass and you think your job is done. Stop to think about your method again; is there something wrong? Your tests pass and you have used common practices so everything should be good. Remember the golden rule – “Always practice defensive programming”. What if I wrote a test looked like:

Ahh, a null pointer exception. Now take a second look at your code. You could go back and add a quick check for a null parameter into your code. What does that really do? Your taking care of the “defensive” programming rule, but at the same time your adding lines of code. Do you really want someone else coming into your project and reading a bunch of wasted if(object==null) statements? Not really. One quick trick would be to reverse the order of your .equals()…

Now what have we done? By simply reversing the order so that the object that is checking for the equality is a known value, we have defended against the possibility of a null value exception. No need to check to see if x is null, rather we would return false, because after all, they aren’t equal. This trick can be applied in other cases, such as casting or returning portions of strings.

I’ll leave this blog open to discussion on other ways to easily protect yourselves against the dreaded null pointer exception…