class A{
public A() throws IOException{ }
void m() throws IOException{ }
}
class B extends A{
//Exception is valid here, but FileNotFoundException is invalid
public B() throws Exception{ }
//FileNotFoundException is valid here, but Exception is invalid
void m() throws FileNotFoundException{ }
}
No, the given explanation and the example code is correct. Please try it out.
Unchecked exceptions have no need to be declared in the throws clause at all. So the rule about subclass/superclass is irrelevant to them.
If you like our products and services, please help us by posting your review here.
It is not possible to define CleanConnector that does not throw IOException at instantiation.
Hmm... Is it just me (could be - it's late and I'm tired), but is that a double negative? I read that as: It is possible to define CleanConnector that does throw IOException at instantiation
So, that's what I chose.
Reading the answer, perhaps the question should be:
It is not possible to define CleanConnector that throws IOException at instantiation.
I don't think you are interpreting it correctly. I see it as, "Is it possible to define CleanConnector that does not throw IOException at instantiation?" Yes, it is (as shown in the option explanation). So the option is incorrect.
If you like our products and services, please help us by posting your review here.
Hi Paul,
Before I started with Enthuware, I tried the mock exams that came with an OCA book written by Boyarski & Selikoff (http://www.amazon.com/OCA-Certified-Ass ... 1118957407).
They frequently state that whenever the code needs an import, like in this exercise (IOException), it should be mentioned in the code explicitly. If that's not the case, we should answer 'does not compile' on the exam. When can we be sure that we don't have to pay attention to the imports in the code? In this example, the answer could therefore be 'does not compile'. But I just guessed that the imports weren't an issue here. But for the exam, I must be sure
In the exam also, you will know when the import is an issue and when it is not. You will know by looking at the options and what the question is asking.
When they say, "The following is a complete code listing...:", that is when you have to consider import statements. Otherwise, most of the time they ignore import statements.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
The reason that the constructor of a subclass must throw a superclass (not subclass) of the exception that superclass' constructor throws, is it a Java agreed upon convention or there is actually a logic flow behind it?
The reason that the constructor of a subclass must throw a superclass (not subclass) of the exception that superclass' constructor throws, is it a Java agreed upon convention or there is actually a logic flow behind it?
Good that you asked. You will rarely find anything in rules of programming in general, and Java in particular, that is not based on logic
So, yes, there is quite a bit of logic behind this rule. Any good Java book will explain it. Not sure which book are you following but
10.3.2 Throwing exceptions from initializers and constructors of Hanumant's book (Page 284) explains it nicely.
And btw, there is no restriction on a subclass' constructor regarding throwing a subclass of exception that superclass' constructor throws. Subclass's constructor is allowed to throw any exception whatsoever as long as it is declared in its throws clause along with the exception declared in the superclass' constructor.
If you like our products and services, please help us by posting your review here.
I'm sure I'm over simplifying it, but after looking the 10.3.2, is it as simple as,
The subclass's constructor has go to the superclass's constructor, so the superclass's constructor better know what is the highest checked exception the subclass' constructor is talking about. While when overriding methods, the method being overridden already knows what the highest exception it has.
It cares because when the subclass' constructor calls the superclass' constructor (not withstanding the case in Note) the superclass' constructor has to have the same or higher class of exception compare to the subclass' constructor.
Note: Of course when the compiler inserts a default constructor for a subclass because we did not provide one with appropriate exceptions as defined in the superclass's constructor, it automatically causes an error.
As I said it, is a oversimplified way of remembering the exception ranking order in constructors and overridden methods.
Is there a more straightforward way to remember this? Thanks
It cares because when the subclass' constructor calls the superclass' constructor (not withstanding the case in Note) the superclass' constructor has to have the same or higher class of exception compare to the subclass' constructor.
It was a rhetorical question. Superclass doesn't care about the subclass simply because superclass is not dependent upon the subclass, subclass is dependent upon the superclass. So, superclass's constructor doesn't have to have anything based on the subclass's constructor. You are going in reverse that is why you are finding it confusing.
The logic is simple - A subclass constructor must always invoke one of the superclass's constructor (directly using super(...) or indirectly using this(...)) and this invocation must be on the first line of code in the constructor. If superclass's constructor says that it throws a particular checked exception, then the subclass constructor has no way to catch that exception. Therefore, it must propagate that exception to the caller and that is why it must declare that exception in its throws clause as well. Thus, if superclass's constructor declares that it throws an Exception E, then the subclass constructor must declare the same exception E or a wider excception i.e. superclass of E in its throws clause.
If you like our products and services, please help us by posting your review here.
So the subclass constructor has to have same or wider checked exception(s) than its superclass constructor, because unlike an overridden method (due to being the first line of code in the subclass), all it can do is to pass the checked exception(s) from the superclass' constructor down the line as it were.
