Interface implementation Exception

Hi ranchers,

Why we cannot use new checked exceptions for interface's implementation methods in the sub class ,but there is no restriction with respect to run time exceptions ?

can you please elaborate on this .

Because an implementation is a refinement of the interface specification; whenever the specification is feasible, the refinement must be feasible. If you throw an Exception, the refinement is no longer feasible, so you are breaching the laws of refinement (and probably the Liskov Substitution Principle, too).

The compiler doesn't check RuntimeExceptions. It doesn't mean you can use RuntimeExceptions, it means the compiler doesn't throw an error. That is different.

I simpler explanation: added a (wider) checked exception changes the method signature while adding a RuntimeException doesn't.

Wouter Oet wrote:I simpler explanation: added a (wider) checked exception changes the method signature while adding a RuntimeException doesn't.

Well, there are several things you can do when overriding or implementing a method that change the signature, which are perfectly legal. You can make a method more public, or you can make the throws clause more restrictive (throwing fewer possible exception types than the original did), or you can make the return type a subtype of the original return type. Changing the signature is allowed - but only changes in specific ways.

Mike Simmons wrote: . . . can make a method more public, or you can make the throws clause more restrictive . . .

Both those things increase the range of feasibility of the method, so they are consistent with refinement.

I think we have all described the same thing in three different ways.

But you can only make changes that compatible with the old one.

Right - I'm just saying that Wouter's simplified explanation is, in my opinion, too simplified, and misleading. We can't decide whether this code will compile using a "does it change the signature?" rule - we have to understand the rules for which changes are compatible. I'm sure the three of us all understand this fine - I'm just talking about how to present it to others.

Although technically, none of these things (exceptions, return type, or access specifier) are part of the signature as defined in the Java Language Specification. So perhaps it's best to agree that no, we can't change the signature when overriding or implementing. But aside from that, we need to understand the rules about what changes are allowed for exceptions, return type, or access specifier.

Agree with MS: if we change the signature, the method is not overridden but overloaded.