Enthuware

This behaviour is exactly opposite from that of methods. The overriding method cannot throw any exception other than overridden method. It may throw subclass of those exception.

I Always try to understand why this is the case, but I can't think of a reason why they made it the opposit from that of methods.

That is simple. Methods are polymorphic (except static and final, of course) while Constructors are not.

Most of such seemingly confusing rules can be easily understood if you understand one simple concept - componentization. What it means is that you should think of developing "components" and developing systems that are made of components. A key property of such a system is that components should be replaceable with other similar components. For example, if you think of a system of a light bulb and its holder, there are two components - a bulb and a holder. You are not forced to use a bulb of the same company. You are free to replace a bulb with any other kind of bulb as long as their component "contract" is satisfied. The objective here is to prevent a system from breaking as much as possible.

Think about a system with two classes - A and B. Let's say A creates an instance of B and then uses B's methods later on. The code where A instantiates B knows that it is instantiating B and has to write the code that will take care of any exceptions that might be thrown while creating B. These exceptions are as per the declaration of B's constructor.

Now, what if you want to change A to use some special B, i.e. a subclass of B. Again, the writer of the code KNOWS that now he is trying to instantiate a subclass of B and is therefore in a position to alter his code accordingly with respect to any new exceptions that this special B's creation might throw. Note that creation of a subclass of B will always involve creation of B so exceptions thrown by B's constructors have to be covered as well anyway.

B b = new SubB(); //The developer knows that this code instantiates a different component and so must be able to change code to handle new exceptions.

Therefore, a constructor is allowed to throw any sort of new exceptions along with the exceptions thrown by the base class's constructor.

But now think of the situation with methods. Consider this:

void methodThatUsesB(B b) throws SomeException{
b.m1();
}

This code should work irrespective of what b points to i.e. to B or to a subclass of B. The writer of this particular code has no idea whether he is receiving an instance of B or an instance of subclass of B. He is no position to change his code (because he receives the actual object at run time, not at compile time) if the instance of B that he receives starts throwing an entirely different exception. If that happens, then the contract breaks.

This can be prevented only if the subclass of B will not throw any new exceptions in its version of m1() that cannot be handled by the code that was already written by someone else. This means the subclass method cannot throw an exception that is higher up the hierarchy or belongs to an entirely different tree.

You should apply the same analogy to return types of methods and figure out why covariant returns are possible.

HTH,
Paul.

Thank you Paul for your long answer.
In the explanation is told: Constructor must declare all the checked exceptions declared in the base constructor (or the super classes of the checked exceptions).
Why a constructor can not declare subclasses of the checked exceptions?

It can declare subclasses of the checked exceptions. But it is not a must. The statement in the explanation is talking about the exceptions that it must declare.

Why option 4 and 5 is not chosen.pls explain .

Because there is no restriction on a subclass constructor about exceptions that it cannot throw. It can throw any exception with appropriate throws clause. The rule is that the subclass constructor must declare that it throws the exception (or superclass of the exception) that is declared in the throws clause of the superclass's constructor.

admin wrote:Because there is no restriction on a subclass constructor about exceptions that it cannot throw. It can throw any exception with appropriate throws clause. The rule is that the subclass constructor must declare that it throws the exception (or superclass of the exception) that is declared in the throws clause of the superclass's constructor.

So you mean that if a parent class constructor throws X exception than its child can throw X exception or (Y)Super type or parent of X.
ie X extends Y.

No, not can. Must. Please read my response again. Try out some test code as well.

Sorry, but it looks rather incorrect to say
"It can throw any exception but it must also throw IOException (or its super class)." (from the test explanation)
Because it does not have to throw any exception, it must DECLARE that it could throw IOException (or its super class).
But it can actually throw any subclass of declared exception.
Am I right?

Yes, it is quite common to say that something "throws some exception" in the context of a throws clause although it would be more precise to say, "declares that it throws some exception".
Updated to make it clear and unambiguous.
thank you for your feedback!

The explanation to option "None of these" has a mistake. This line says: it should say
I think option 3 explains it better with:

It can throw any exception but it must also declare that it throws IOException (or its super class).

No, "//IOException is required here", would be wrong because even throws Exception is valid.

The explanation is trying to convey a different point. It is showing the difference in the rule of throws clause for method and constructor.
Please read the whole explanation together instead of reading one line in isolation.

The point that you are making is explained in the previous explanation.

I think there's some room for improvement there, if you don't it's fine.

Sure, we will improve. thanks for your feedback!

Could you please review explanations? For example answer 1 - not correct example and 6 - "A constructor is free to throw any exception." but it tells "constructor of a subclass cannot throw subclass exception" and etc

According to Barbara Liskov's book (Program Development in Java: Abstraction, Specification, and Object-Oriented Design) :

From Chapter 7 - Type Hierarchy:
It inherits from its superclass the implementations of the final methods and any normal methods that it does not override. Any methods it overrides must have signatures identical to what the superclass defines, except that the subclass method can throw fewer exception types.

Liskov mentions here that overridden methods can throw fewer exception types. The general purpose is to provide the signature rule of the substitution principle. If you do not do this, you will violate this rule.




I just wanted to contribute to the admin's answer.

Best Regards.

hsnclk thank you for the answer.
Does this book recommend by Oracle for this exam? if not its a bad idea to use it. Best practices or good recommendations are not for this exam. Java has some bugs or features, depend on point of view and Oracle ask you about these features. From version to version they may migrate, new come the old go out.

The information I shared is entirely related to this question. It has nothing to do with the exam. Whether or not you read the book is optional. Of course, some things in the book are out of date. But I recommend reading it to understand why some concepts exist.

Of course, this is just my suggestion.