Re: Overloading, Overriding or an Error?
On 3/15/2011 3:52 PM, Steve wrote:
I have a bit of a quiz question here.
Overriding is when a subclass defines a method with the same signature
as a method in a superclass. Same argument list, same return type,
the same or the same or less extensive exception handling.
Overloading is reusing the name of a method, with the minimum
requirement of changing the argument list.
So, given these 2 things ( correct me if I am wrong ), if a method in
a subclass changes a return type, makes more comprehensive exception
handling or both.........is it an compile time error or is it
overloading?
Concerning the return type: If it's a subclass (or sub-interface)
of the superclass' return type, all is well. Otherwise, it's a
compile error. For example, if the superclass method returns a
Number and the subclass' returns an Integer, everything's fine --
but if the subclass' method returns a JButton, the compiler whines.
Concerning exceptions, we must distinguish between checked and
unchecked. The subclass' method can throw whatever unchecked
exceptions it pleases, without restriction, no matter what the
superclass' method throws or doesn't. When it comes to checked
exceptions, though, the subclass' method can only throw subclasses
of the superclass' exceptions. If the superclass' method throws
IOException, it's fine for the subclass' method to throw
FileNotFoundException, because FNFE is a subclass of IOE. But the
other way around wouldn't work: If the superclass throws FNFE, the
compiler won't let the subclass throw the more general IOE, nor the
completely unrelated ConcurrentModificationException.
Think of it from the caller's point of view: The caller writes
something like
Thing thingy = thingFactory.getInstance("whingding");
Collection contents = thingy.getContent();
We want this call to be correct no matter whether the thingFactory
gives us a "basic" Thing or some subclass of Thing, possibly a
subclass that isn't even known when the call is compiled. The only
way we can be sure it's right is if every subclass of Thing has a
getContent() method returning something that can pass as a Collection:
A Set, or a List, or a BeanContext, but not a PrintStream. Also, if
Thing's getContent() throws a checked exception of some kind, it must
be inside a try block that catches that exception or in a block that
declares that exception to be thrown -- so if the code is to be correct
no matter what Thing subclass is actually in play, it follows that the
subclass mustn't throw exceptions that aren't already being dealt with.
The superclass (or interface) has a sort of "contract" that tells
callers what they must do, and all subclasses (sub-interfaces) must
obey that same contract to preserve the integrity of the callers.
--
Eric Sosman
esosman@ieee-dot-org.invalid