• Post Reply Bookmark Topic Watch Topic
  • New Topic

about constructor  RSS feed

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question 193)
Read the following piece of code carefully. (This is an extention to question 72.)
import java.io.IOException;

public class Question72
{
public Question72() throws IOException
{
throw new IOException();
}
}
public abstact class Question73 extends Question72
{
public abstract void method();
}
An attempt to compile the above class definition
will cause a compiler error - non-abstract classes cannot be extended to abstract classes.
will cause a compiler error - a constructor must be provided which may or may not throw an IOException
will cause a compiler error - a constructor must be provided which must throw an IOException or one of its super types.
will not cause any compiler error. The class definition is perfectly legal.
the ans is 3rd.why? Does that mean if the constructor of the superclass throwed an checked exception, an explicit constructor(no default one) in the subclass must be provided.
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the constructors behaves exactly the opposite as the methods regarding the checked exceptions that declare to throw. The must declare the same (or supertypes) exceptions as the base constructor does. Also they can declare more if they want.
 
Sheriff
Posts: 11702
190
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason the compiler complains is that the default constructor will make an implicit call to super(). From there, it behaves as any other method does with regard to checked exceptions: you either have to handle it or throw it, too. The default Question73 constructor does neither, thus the compiler error telling you that you need to provide an explicit constructor that either handles the exception or throws it.
As for Jose's comment about throwing more exceptions or supertypes of the declared exception: Yes, you can do this but I think it would be an invitation to trouble. One OO design principle (see "The Liskov Substitution Principle") is that you should be able to use a subclass anywhere you use a superclass without breaking the code
If a subclass throws a broader range of exceptions than it's superclass, then the LSP would be violated.
Junilu

[This message has been edited by JUNILU LACAR (edited January 01, 2002).]
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I said


the constructors behaves exactly the opposite as the methods regarding the checked exceptions that declare to throw.


I forgot to mention that I was meaning the behaviour of the overriden methods and the checked exceptions they declare:
An overriding method is allowed not to declare any of the exceptions declared in the overriden method, but they can not add any exception not mentioned in the overriden method. The reason is the Liskov principle.
I tried to compare this behaviour with the related one to the base and derived constructors: a derived constructor must declared all checked exceptions that the base version does. Also it can add any exception else. Note that the reason for this behaviour is not the Liskov principle. Because now we are referring to the exceptions possibly thrown when constructing objects, not the ones possibly thrown when passing to a method an argument of a base declared type, but containing a reference to an instance of a derived class. The reason for the behaviour of the declared checked exceptions in both base and derived constructors is: when constructing an object of a derived class always it will be possible to throw the exceptions declared in the base class. Just because the base constructor must be excecuted.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!