Overriding - returns and exceptions

[Sanjeev Ba]

Is it fair to say exceptions and return values have similar rules while overriding methods in subclasses?
(excluding runtime exceptions and freedom not to return exception)

They can return either the class type or the subclass type as return values/exception type.
Cannot return super class type as return value / exception type.
Cannot return new exception / return type.

There is much similarity here.

[gurpeet singh]

Sanjeev Ba wrote:Is it fair to say exceptions and return values have similar rules while overriding methods in subclasses?
(excluding runtime exceptions and freedom not to return exception)

They can return either the class type or the subclass type as return values/exception type.
Cannot return super class type as return value / exception type.
Cannot return new exception / return type.

There is much similarity here.

yes there are similarities. the difference can be that you can throw NO checked exceptions in your overridding method.

[John Jai]

Cannot return super class type as return value / exception type.

The above statement is correct. It can only return declared or sub-class of the declared checked exception.

[Nitish Bangera]

Yes the similarity over here is co-variance which is similar for object return types or exceptions thrown which would be object of the Exception Classes.

[Matthew Brown]

You're right that it's similar. In fact, the rules are as they are for exactly much the same reason. In each case, they're the only way the compiler can enforce the rules correctly. Consider this bit of code:

class Superclass {
    public SomeType getValue() throws SomeException {
        ....
    }
}

class Subclass extends Superclass {
    public XXX getValue() throws YYY {
        ....
    }
}

So, what are the restrictions on XXX and YYY? And why? Now consider this:

Superclass obj = new Subclass();
try {
    SomeType value = obj.getValue();
}
catch (IOException ex) {
    ...
}

As far as the compiler is concerned, obj is a Superclass. So the method returns a SomeType, and throws a SomeException. So that's fine - that will compile OK. But at runtime, obj is a Subclass object. Which means:

- We're assigning an XXX value to a SomeType value.
- We might be throwing a YYY exception. If this is checked, it must be handled by the try/catch block.

The only way we can satisfy these is if XXX is SomeType or a subclass. And YYY can't include any checked exceptions that aren't SomeException or a subclass.

These rules are both related to the Liskov Substitution Principle: an instance of a class must always be replaceable by an instance of a subclass.