Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Replace .equals() with Objects.equals()

Tags:

java

I was writing code, when IntelliJ suggested me a correction on:

objectOne.equals(objectTwo);

telling me that the Method invocation equals may produce the good old java.lang.NullPointerException , proposing as solution something that I wasn't aware of, Objects.equals:

Objects.equals(objectOne, objectTwo);

Reading the documentation I see only one potential problem, which is that if objectOne == null and objectTwo == null , then the result is true.

At this point the question is: could I start replacing and using everywhere this method instead of .equals ? Is this a safe approach or I'm missing some big contraindication?

Getting rid of NPE is very attractive... Thanks

like image 752
Leviand Avatar asked Sep 20 '18 15:09

Leviand


People also ask

Can you use equals () with objects?

The equals() method is a static method of the Objects class that accepts two objects and checks if the objects are equal. If both the objects point to null , then equals() returns true .

Do all objects have an equals () method?

Every Object in Java includes an equals() and a hashcode() method, but they must be overridden to work properly. To understand how overriding works with equals() and hashcode() , we can study their implementation in the core Java classes. Below is the equals() method in the Object class.

What is the difference between == Object equals ()?

The major difference between the == operator and . equals() method is that one is an operator, and the other is the method. Both these == operators and equals() are used to compare objects to mark equality.

What does the equals () method is inherited from Object do?

The Inherited Equals Method from Object. The equals method that is inherited from the Object class only returns true if the two objects references refer to the same object.


3 Answers

There is NO bulletproof answer for this question, as it depends on the needs of the program and how it should answer to that exceptional scenario. Saying that, i would say:

If having a null is a programmer's error (I mean something that you will never expect to happen inside your algorithms) i would suggest to leave the .equals method as a null pointer exception will arises and make you notice of the problem, i mean, a programmer's error (Those errors that we don't want!, that means that we wrote bad an algorithm), and you should thanks the application for reporting it (instead of an angry real client....)

But if in the other hand your application could work as well, not considering that as a progrmmer error, then using Object.equals will fit better to your needs.

The general wisdom suggest that exceptions should at leats be logged.

Hope it helps!

TD;DR;

Try to investigate about differnet kinds of exceptions. Not all the exceptions are programmer errors.

In java, usually, the checked exceptions are for all those events that you can anticipate, you can write code that should be able to handle. And the unchecked Exceptions (those that belongs the RuntimeException's family) are for events that you just can not anticipate (like null pointer exceptions), thus it is imposible to write code to handle things that you don't expect (instead you should correct the already existing code, not write new!)

like image 103
Victor Avatar answered Nov 09 '22 23:11

Victor


It is an appropriate approach if you want to allow null values. Otherwise you could just add a check for null values and handle them appropriately.

like image 23
jobber2345 Avatar answered Nov 10 '22 01:11

jobber2345


Depends on your code and what 'everywhere' means. If your code currently assumes (maybe not explicitly but just by the fact that null input will never propagate beyond the equals call ) that null input will result in an NPE, then switching to Objects.equals will introduce a bug.

like image 45
David Soroko Avatar answered Nov 10 '22 01:11

David Soroko