• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exceptions, overriding and constructors

 
nick woodward
Ranch Hand
Posts: 370
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like the new moose..... who is it?

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?

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?

It sounds right now that I've typed it out, but I wouldn't mind checking!

Thanks,

Nick
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nick,
Your understanding/explanation is correct.

Today's "moose" is Bear Bibeault with antlers. Today is Have a party with your Bear day. Bear was a good sport and let us use his picture to celebrate.

This is the moose (so people seeing it tomorrow know what this is about)
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 370
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne - I thought I recognised him from somewhere, a 'meet the team' (or equivalent) page? Anyway, new logo confirmed

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


Hi Roel,

I did not know that about hidden methods - I assume the same reasoning is behind that too?

As for the second link - I think it does, although I'm not 100% sure of the question being asked in that thread! But yes, I think it confirms what I think. Thanks!

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!

Regards,

Nick


** edit: yes, the initialisation requires a try/catch, the declaration doesn't, and I'm not sure why it's not declared thrown in the class definition/or what I'm actually asking ;)
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 370
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


JLS

and sorry, i meant hidden as in static rather than private. you've lost me!

i'm just confused why if static methods hide superclass methods they need to follow the rules that overriding abide by.

apologies Roel, I don't think I'll get it tonight however well you explain it! will have to give it another try tomorrow morning!

thanks again though,

Nick
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
nick woodward wrote:and sorry, i meant hidden as in static rather than private. you've lost me!

The example I described was about class methods It was just describing this use caseAnd then B defines the same method but with a private access modifierSo it was all about class methods

nick woodward wrote:i'm just confused why if static methods hide superclass methods they need to follow the rules that overriding abide by.

I think the most simple (but maybe not 100% technically correct) explanation is: when you override a superclass method, the subclass method replaces that superclass method. But you can't do any replacement, so there are some replacement rules (aka the rules for overriding methods), e.g. you can't narrow the access modifier. Now if you define a static method in the subclass which has the same signature as a static method in a superclass (like in the previous code snippet), that subclass method replaces the superclass method as well. So those replacement rules apply here as well.
 
nick woodward
Ranch Hand
Posts: 370
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually thinking about it you're right, I suppose the rules about the method signature make sense, in order to ensure that the superclass method is hidden and that there aren't two identically named methods with slightly varying signatures (which wouldnt' be allowed)

I was just struggling to see why throwing broader exceptions could be a problem with statics, because surely there won't be ambiguity calling a static from a superclass reference due to a lack of polymorphic call. If I'm understanding this all correctly!

Roel De Nijs wrote: that subclass method replaces the superclass method as well. So those replacement rules apply here as well.


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!!

Regards,

Nick
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!!

Yeah, I think it's indeed more about consistency (and thus easier learning, hooray ) than about a possible scenario where it really could make a difference. Simply because as you said there's no polymorphic behavior, so based on the class type (or the type of the reference variable) you know without any doubt which static (class) method has to be invoked.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic