[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
nick woodward wrote:Anyway, I understand that overriding methods cannot throw broader checked exceptions - in order to allow polymorphic programming and prevent problems with exceptions thrown at runtime, correct?
nick woodward wrote:But is the opposite true with constructors (that you can't throw narrower or fewer) simply because as a subclass they have the ability to throw the superclass exception on construction?
Roel De Nijs wrote:
nick woodward wrote:Anyway, I understand that overriding methods cannot throw broader checked exceptions - in order to allow polymorphic programming and prevent problems with exceptions thrown at runtime, correct?
That's indeed one of the rules for a valid override. The overriding method can only throw narrower or fewer checked exceptions. Did you know it applies to static methods as well, although they are not inherited (and thus can't be overridden)? Read this post to find out more.
nick woodward wrote:But is the opposite true with constructors (that you can't throw narrower or fewer) simply because as a subclass they have the ability to throw the superclass exception on construction?
Does this topic answer your question?
Hope it helps!
Kind regards,
Roel
nick woodward wrote:I did not know that about hidden methods - I assume the same reasoning is behind that too?
nick woodward wrote:Quick question though - much like you place a try catch around a method that throws an exception, does the same apply to the declaration and/or initialisation of an object? And related to that, if it isn't in a try block, does the class have to declare the same exception as the constructor? Sorry, that's a bit lazy of me, I'm going to check now!
Roel De Nijs wrote:
nick woodward wrote:I did not know that about hidden methods - I assume the same reasoning is behind that too?
The requirements for hiding and overriding are listed in the same section in the JLS. That's already a very good reasoning And otherwise you'll probably end up with strange use cases. For example, class A has a public class method go() and class B extends from A. So with B.go() you could invoke that method from anywhere. And then class B defines the same go() method but with the private access modifier. And for the outside world, the go() method suddenly has disappeared. Smells a bit fishy, isn't it?
nick woodward wrote:Quick question though - much like you place a try catch around a method that throws an exception, does the same apply to the declaration and/or initialisation of an object? And related to that, if it isn't in a try block, does the class have to declare the same exception as the constructor? Sorry, that's a bit lazy of me, I'm going to check now!
As you already discovered yourself: yes! And the reason is very simple: the handle-or-declare rule applies to every checked exception. It doesn't matter if this checked exception was thrown from a method or a constructor. It's a checked exception, so the compiler will do its magic.
nick woodward wrote:and sorry, i meant hidden as in static rather than private. you've lost me!
nick woodward wrote:i'm just confused why if static methods hide superclass methods they need to follow the rules that overriding abide by.
Roel De Nijs wrote: that subclass method replaces the superclass method as well. So those replacement rules apply here as well.
nick woodward wrote:I mean, yeah, it does, but I don't think the rule RE exceptions makes much sense (or at least I can't personally think of a scenario where it would matter), but at least it makes learning slightly easier if they're just the same!!