• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exceptions, overriding and constructors

 
Ranch Hand
Posts: 386
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 386
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 386
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 386
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic