• Post Reply Bookmark Topic Watch Topic
  • New Topic

Interface implementation Exception  RSS feed

 
karimkhan pathan
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 .

 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I simpler explanation: added a (wider) checked exception changes the method signature while adding a RuntimeException doesn't.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But you can only make changes that compatible with the old one.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with MS: if we change the signature, the method is not overridden but overloaded.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!