About Question enthuware.ocajp.i.v7.2.1143 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by admin »

Brian B wrote:The verbiage of the question says:

"...are correct for a method that overrides the following method:"

Isn't the answer "It can be abstract" a little misleading?

Considering, that an abstract method cannot have a method body, if you were to create an abstract class (as you'd be required to do if you declare a method abstract) wouldn't you have a completely separate method?
No, I do not agree that you would have a completely separate method. I am not sure why do you think so.
Wouldn't declaring it abstract violate the rule ("same return type in case of primitives (a subclass is allowed for classes, this is also known as covariant return types"). given in the explanation for overriding a method?
Not sure what you mean. Can you please provide some code to illustrate your point? Return type of a method has nothing to do with it being abstract or not.
Based on your further explanation here:

"...You are right it is not actually overriding the method because there is no implementation. But look at it other way, the subclass is indeed giving a new behavior to this method and that is that the method has to be implemented by another subclass. This behavior is different from the original method (which does not force a subclass to override it) and in that sense it is overriding the original method."

If a subclass extends the abstract class, which you create to make the original method abstract, wouldn't the subclass be overriding the abstract method, not the original method presented in the question?
Sure, but the question is above overriding the original method. You can override it with an abstract method. I agree that it doesn't seem to natural but there is nothing wrong with it technically. Putting it another way, what would you call it if a subclass has the same method as its super class but has made it abstract. I think calling it overriding is ok.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Brian B
Posts: 13
Joined: Mon Jun 16, 2014 1:07 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by Brian B »

Paul,

I stand corrected. As usual, you are right. :D I don't know why or how I coded it the first time through but it had me convinced that the subclass was implementing the abstract method (which is true) but not overriding the superclass method. I coded it again and put in @override annotations to see if they were, in fact, both considered to be overriding methods by the JVM:

class A {

public String getSet(int a) {

return ("in class a");
}
}

abstract class B extends A {

@Override
public abstract String getSet(int a);
}

class C extends B {

@Override
public String getSet(int b) {
return ("in class c");
}
}

public class TestClass {

public static void main(String[] args) {

}
}

Sure enough, it compiles without error. I think my confusion was with the syntax of the abstract method. Because a method that declares a return type must return a value (which would require a method body) that abstract methods do not allow. The method body, however, doesn't have anything to do with an abstract method's ability to still declare the same return type and signature as the method it is overriding.

That's why you write the test and I'm merely trying to pass it! :D

coder007
Posts: 25
Joined: Wed Dec 17, 2014 9:29 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by coder007 »

In explanation we read:
.It may throw only those exceptions that are declared in the throws clause of the superclass's method or exceptions that are subclasses of the declared exceptions.
It is only about checked exceptions?
I thought that in overriding method we can declare (in throws clause) any type of unchecked exceptions even if they weren't declared in overridden method. Am I right?

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by admin »

Yes, of course, the restrictions about the throws clause are only for checked exceptions. Unchecked exceptions have no restrictions. You can declare or throw any unchecked exception anywhere. That is why they are called "unchecked". They are not checked by the compiler.
If you like our products and services, please help us by posting your review here.

fommof
Posts: 1
Joined: Fri Jan 13, 2017 6:05 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by fommof »

Hi to all,

May I ask why the statement "It can be abstract." is correct when the method in the description has a body?

public Set getSet(int a) {...}

As it is, it can be a method of an abstract class (not an abstract one). But if you just add the "abstract" keyword and leave it as it is, you will have an abstract method with a body, so it won't compile.

What am I missing?

Thanks in advance,

Nick

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by admin »

The question doesn't mention anything about the class in which the overriding method exists. So you have to assume that the class will be declared appropriately.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Deleted User 3513

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by Deleted User 3513 »

"I can throw RuntimeExceptions anywhere because it doesn't have to be handled or declared" -> is this correct? So even if I did not declare it in the super class method(throws RuntimeException), and in the sub class method I declared it(throws RuntimeException) this is valid because of RuntimeException's condition that I don't have to handle or declare it. Does the Java secretly include this in code that's why it acts this way?

I tried it, and it compiled and ran successfully, but I'm just a bit confused on how this happens in the background.

Code: Select all

class Yes extends OtherClass{
	OtherClass oc = new OtherClass();
	public void rte() throws RuntimeException{}
}

class OtherClass implements Yeah{
	public static void main(String[] args){
		System.out.println("from OtherClass");
	}
	public void rte() {}
}

interface Yeah{
	public abstract void rte();
}


admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by admin »

RuntimeException, Error, and their subclasses are called "unchecked" exceptions. These are called unchecked because the compiler doesn't check for the possibility of these exceptions. So basically, it is not the JVM but the compiler that makes your code compile. The reason it behaves this way is because that is how it is designed by the Java language creators.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

enthunoob
Posts: 60
Joined: Thu Apr 15, 2021 12:21 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by enthunoob »

Even though already explained above, adding the following text to the explanation of option 4 would make instantly clear:

A method can throw any RuntimeException (such as a NullPointerException) even without declaring it in its throws clause because it is an unchecked exception.

Assuming that would be a correct statement ofcourse :)

It would mean that declaring Error in throws clause is also always possible, as it is also an unchecked one. Is that correct?

admin
Site Admin
Posts: 10065
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1143 :

Post by admin »

Good point. Added.
thank you for your feedback!
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 114 guests