-1

This is a question that is being around in my head for days.

When it comes to inheritance and polymorphism, Java support covariant return types through the bridge method concept.

But why doesn't they implement a concept like bridge method to the methods that don't have throws clause in the superclass, but has a throws clause when it is overridden in the subclass. Or can't they add the throws to the method signature to overcome this problem.

From this post,

I get the idea that when override a method from a superclass, the checked exceptions that the subclass method declares cannot be more general than those of the superclass method.

But why can't we override a method that doesn't have a thorws in the superclass, but to have it in the subclass.

Why my suggestions can't be applied to the Java mechanism.

Can someone explain it to me

Clarke
  • 185
  • 10
  • 2
    Liskov substitution principle: when client code deals with the superclass interface, and it says "no exceptions", and then you call a method on the subclass, and some exception is thrown ... what then?! Doesnt make sense conceptually. – GhostCat May 12 '20 at 11:55
  • @GhostCatsalutesMonicaC I get what you say now. But one more question. Can I think that "Liskov substitution principle: when client code deals with the superclass interface", as an abbreviation of Liskov substitution principle? – Clarke May 12 '20 at 14:11
  • That principle says that the right way to design for polymorphism by making sure that any place where a super class object is used still works when it gets to use a child class object. Because that allows to only change the incoming object to be different, whereas code dealing with these objects can stay the same. – GhostCat May 12 '20 at 15:05
  • @GhostCatsalutesMonicaC. But when we think like that principle, having `throws` or not having it in the method implies that it is part of the method signature? isn't it? Otherwise how can the compiler recognise that the subclass method is different than the superclass – Clarke May 12 '20 at 15:58
  • Note that I am not talking about Java specifically but the liskov principle in general. That is why I emphasized the design aspect. Compilers are very helpful, but in the end, it is the job of the human programmer to create a sound solution that considers issues that a compiler here or there might not care about. – GhostCat May 12 '20 at 19:26
  • @GhostCatsalutesMonicaC. Yeah I got that. I have understood that principle – Clarke May 12 '20 at 19:36

1 Answers1

0

The throws clause is ignored by the JVM verifier, so there is no need for a bridge or other synthetic method.

The compiler enforces the language constraint that the throws specification is no broader than the overridden method. This is the same covariant behaviour as for return types (since 1.5). Answers to the linked question demonstrate why this is the case.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • Can you explain a little bit about "The compiler enforces the language constraint that the `throws` specification is no broader than the overridden method" more. Because the linked question doesn't say about not having `throws` in the superclass method and having it on the subclass method, please that would help me a lot – Clarke May 12 '20 at 14:16
  • @Clarke If there is no `throws` clause then there is still the implicit `RuntimeException` and `Error`. There's still an exception specification there. The compiler will prevent the method throwing, for example, `IOException`. – Tom Hawtin - tackline May 12 '20 at 14:56
  • So it is like if an exception is raised in the method, it should definitely be thrown. since the superclass doesn't throw it, compiler raises an error. Am I correct? – Clarke May 12 '20 at 16:03