Now, you know a method without void return type must return something and the only way it can get out of returning something is to throw an Exception. If it always returns something, that does not allow for Exceptions. That means that equals() methods are not permitted to throw Exceptions. Now what about this sort of implementation of equals:-That is an incorrect implementation because it will throw a null pointer exception if you pass a null reference. There is no problem about getClass() because I marked the class final.
The API's 4th & 5th bullet points wrote:for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
For any non-null reference value x, x.equals(null) should return false.
And you can find even stranger design in this class.
A few minutes ago, I wrote: . . . they thought it should be an Error . . .
Suppose a superclass method declared as "int returnNum() throws CloneNotSupportedException" is overriden in subclasses.
Which of the following overriding declarations in subclasses are improper?
int returnNum() throws RuntimeException int returnNum() throws AssertionError int returnNum() int returnNum() throws Exception
Shaddy Khan wrote:An overriding method can throw all, none, subset or subclass exceptions of the exceptions declared in throws class of overridden method, in case of checked exceptions. Compiler validates this rule in case of "checked exception only" and not in case of unchecked exceptions defined in throws clause.
No. They have the same signature and are therefore not overloaded.
Sreevatsa Turuvekere Laxmi Narayana wrote: . . .
Can options 1 and 2 be considered as overloading instead as overriding?
. . .