Overwrite Default Constructor ?

Discussion in 'Java' started by Philipp Leitner, Apr 17, 2006.

  1. hi all,

    this may be a silly question, but is there actually any way to
    _overwrite_ a constructor of a superclass in Java?

    I have the following inheritance structure:

    "ProfileAdmin" inherits from "ProfileSearcher"

    both classes are almost identical, the main difference is that the
    constructor of ProfileSearcher throws an exception in certain
    circumstances, while ProfileAdmin should try to repair the problem in
    these cases (with the reason that ProfileSearcher should be used on thin
    clients, which are not capable of the cpu-heavy repair actions).

    My first idea would have been to just overwrite the constructor of
    ProfileSearcher, but I quickly discovered that javac inserts an implicit
    "super()" at the beginning of the subclasses' constructor (I really had
    no clue about that in advance ...) :-(

    Any tips on how to solve this issue in a clean way?

    thx in advance,
    Philipp

    --
    Philipp Wolfgang Leitner, Bakk.rer.soc.oec.
    0225511
    Vienna University of Technology

    "Ask five economists and you'll get five different explanations (six if
    one went to Harvard).
    -- Edgar R. Fiedler"
    Philipp Leitner, Apr 17, 2006
    #1
    1. Advertising

  2. Oliver Wong wrote:
    >
    > "Philipp Leitner" <> wrote in message
    > news:4443cbe1$0$11352$...
    >>
    >> "ProfileAdmin" inherits from "ProfileSearcher"
    >>
    >> both classes are almost identical, the main difference is that the
    >> constructor of ProfileSearcher throws an exception in certain
    >> circumstances, while ProfileAdmin should try to repair the problem in
    >> these cases (with the reason that ProfileSearcher should be used on
    >> thin clients, which are not capable of the cpu-heavy repair actions).

    >
    > You could have ProfileAdmin catch the exception. But are you sure
    > ProfileAdmin should be a subclass of ProfileSearcher?


    Tricky to catch an exception thrown from a super constructor call...

    > Perhaps you can add a protected constructor in ProfileSearcher which
    > "does nothing" (or at least, doesn't throw exceptions), which your
    > subclasses (e.g. ProfileAdmin) could use.


    Yup. I'd go further to suggest making non-leaf classes abstract.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Apr 17, 2006
    #2
    1. Advertising

  3. Philipp Leitner

    Oliver Wong Guest

    "Philipp Leitner" <> wrote in message
    news:4443cbe1$0$11352$...
    > hi all,
    >
    > this may be a silly question, but is there actually any way to _overwrite_
    > a constructor of a superclass in Java?


    Not to my knowledge.

    >
    > I have the following inheritance structure:
    >
    > "ProfileAdmin" inherits from "ProfileSearcher"
    >
    > both classes are almost identical, the main difference is that the
    > constructor of ProfileSearcher throws an exception in certain
    > circumstances, while ProfileAdmin should try to repair the problem in
    > these cases (with the reason that ProfileSearcher should be used on thin
    > clients, which are not capable of the cpu-heavy repair actions).


    You could have ProfileAdmin catch the exception. But are you sure
    ProfileAdmin should be a subclass of ProfileSearcher?

    >
    > My first idea would have been to just overwrite the constructor of
    > ProfileSearcher, but I quickly discovered that javac inserts an implicit
    > "super()" at the beginning of the subclasses' constructor (I really had no
    > clue about that in advance ...) :-(
    >
    > Any tips on how to solve this issue in a clean way?


    Perhaps you can add a protected constructor in ProfileSearcher which
    "does nothing" (or at least, doesn't throw exceptions), which your
    subclasses (e.g. ProfileAdmin) could use.

    - Oliver
    Oliver Wong, Apr 17, 2006
    #3
  4. Philipp Leitner

    Oliver Wong Guest

    "Thomas Hawtin" <> wrote in message
    news:4443da87$0$9274$...
    > Oliver Wong wrote:
    >>
    >> "Philipp Leitner" <> wrote in message
    >> news:4443cbe1$0$11352$...
    >>>
    >>> "ProfileAdmin" inherits from "ProfileSearcher"
    >>>
    >>> both classes are almost identical, the main difference is that the
    >>> constructor of ProfileSearcher throws an exception in certain
    >>> circumstances, while ProfileAdmin should try to repair the problem in
    >>> these cases (with the reason that ProfileSearcher should be used on thin
    >>> clients, which are not capable of the cpu-heavy repair actions).

    >>
    >> You could have ProfileAdmin catch the exception. But are you sure
    >> ProfileAdmin should be a subclass of ProfileSearcher?

    >
    > Tricky to catch an exception thrown from a super constructor call...


    I was aware of the rule that "super()" has to be the first statement,
    but I wasn't aware that a "try-catch" block "counts" as a statement. So I
    tried the obvious:

    <code>
    public class Foo {
    public Foo() {
    try {
    super();
    } catch (Throwable t) {

    }
    }
    }
    </code>

    and indeed it doesn't compile.

    - Oliver
    Oliver Wong, Apr 17, 2006
    #4
  5. well, I tried the same before myself ... and yes, this doesn't compile ...

    for now I went with the idea with a "dummy" protected constructor, but I
    have to say I don't like the solution much. Perhaps I am really going to
    change the inheritance into an aggregation of some kind.

    /philipp

    Oliver Wong schrieb:
    > "Thomas Hawtin" <> wrote in message
    > news:4443da87$0$9274$...
    >> Oliver Wong wrote:
    >>>
    >>> "Philipp Leitner" <> wrote in message
    >>> news:4443cbe1$0$11352$...
    >>>>
    >>>> "ProfileAdmin" inherits from "ProfileSearcher"
    >>>>
    >>>> both classes are almost identical, the main difference is that the
    >>>> constructor of ProfileSearcher throws an exception in certain
    >>>> circumstances, while ProfileAdmin should try to repair the problem
    >>>> in these cases (with the reason that ProfileSearcher should be used
    >>>> on thin clients, which are not capable of the cpu-heavy repair
    >>>> actions).
    >>>
    >>> You could have ProfileAdmin catch the exception. But are you sure
    >>> ProfileAdmin should be a subclass of ProfileSearcher?

    >>
    >> Tricky to catch an exception thrown from a super constructor call...

    >
    > I was aware of the rule that "super()" has to be the first statement,
    > but I wasn't aware that a "try-catch" block "counts" as a statement. So
    > I tried the obvious:
    >
    > <code>
    > public class Foo {
    > public Foo() {
    > try {
    > super();
    > } catch (Throwable t) {
    >
    > }
    > }
    > }
    > </code>
    >
    > and indeed it doesn't compile.
    >
    > - Oliver
    Philipp Leitner, Apr 17, 2006
    #5
  6. Philipp Leitner

    Roedy Green Guest

    On Mon, 17 Apr 2006 19:42:02 GMT, "Oliver Wong" <>
    wrote, quoted or indirectly quoted someone who said :

    >but I wasn't aware that a "try-catch" block "counts" as a statement. So I
    >tried the obvious:


    To avoid the violating the super comes first rule, you need something
    like this:

    super( doeseverythingbuteat( parm1 ) );

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 17, 2006
    #6

  7. > To avoid the violating the super comes first rule, you need something
    > like this:
    >
    > super( doeseverythingbuteat( parm1 ) );
    >


    sorry, I don't get that ;-) How would something like that help me catch
    the exception that super() throws?

    /philipp
    Philipp Leitner, Apr 17, 2006
    #7
  8. Philipp Leitner wrote:
    >
    >
    >> To avoid the violating the super comes first rule, you need something
    >> like this:
    >>
    >> super( doeseverythingbuteat( parm1 ) );
    >>

    >
    > sorry, I don't get that ;-) How would something like that help me catch
    > the exception that super() throws?
    >
    > /philipp


    It doesn't, but it may help you prevent the exception. In some cases you
    could check for the condition that causes the exception, and prevent it
    from happening. It is most useful for things like incorrect parameters.

    Patricia
    Patricia Shanahan, Apr 17, 2006
    #8
  9. Philipp Leitner

    Roedy Green Guest

    On Mon, 17 Apr 2006 22:34:31 +0200, Philipp Leitner
    <> wrote, quoted or indirectly quoted someone
    who said :

    >> super( doeseverythingbuteat( parm1 ) );
    >>

    >
    >sorry, I don't get that ;-) How would something like that help me catch
    >the exception that super() throws?


    It wouldn't, but you could do a test to detect the condition that
    would upset super and handle it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 17, 2006
    #9

  10. > It doesn't, but it may help you prevent the exception. In some cases you
    > could check for the condition that causes the exception, and prevent it
    > from happening. It is most useful for things like incorrect parameters.


    ok, now I get what you meant; unfortunately this would be quite strange
    (if not impossible) to do in my case since I heavily depend on member
    variables.

    /philipp
    Philipp Leitner, Apr 17, 2006
    #10
  11. >Any tips on how to solve this issue in a clean way?

    Investigate the "Factory" design pattern.
    James Of Tucson, Apr 17, 2006
    #11
  12. Philipp Leitner wrote:
    >
    >> It doesn't, but it may help you prevent the exception. In some cases you
    >> could check for the condition that causes the exception, and prevent it
    >> from happening. It is most useful for things like incorrect parameters.

    >
    >
    > ok, now I get what you meant; unfortunately this would be quite strange
    > (if not impossible) to do in my case since I heavily depend on member
    > variables.
    >
    > /philipp


    Here's another approach. Make the ProfileAdmin constructor private, have
    it throw the exception, and supply a static factory method.

    The factory method could wrap the attempt to create the object in a
    try-catch, and do whatever fix-up it likes on catching the exception.
    Make sure the exception carries enough data for the constructor caller
    to know what fix-up is needed.

    Patricia
    Patricia Shanahan, Apr 17, 2006
    #12
  13. Philipp Leitner wrote:
    > well, I tried the same before myself ... and yes, this doesn't compile ...
    >
    > for now I went with the idea with a "dummy" protected constructor, but I
    > have to say I don't like the solution much. Perhaps I am really going to
    > change the inheritance into an aggregation of some kind.
    >


    If these classes really do need to be bound in by Inheritance rather
    than delegation, then the best approach for your design problem is to
    not use public constructors at all.

    Instead, use public factory methods on those classes, protected
    constructors and move all logic from constructors into init methods.
    This way, you can get full control over what happens.

    class Base {
    protected Base() {
    }

    protected init(
    if (someCondition)
    throw new RuntimeException();
    }

    public static Base createBase() {
    Base base = new Base();
    base.init();
    return base;
    }
    }

    class Derived extends Base {

    protected Derived() {
    }

    protected init() {
    try {
    super.init();
    catch(RuntimeException re) {
    system.out.println(re);
    }
    }

    public static Derived createDerived() {
    Derived derived = new Derived();
    derived.init();
    return derived;
    }

    }
    Andrew McDonagh, Apr 17, 2006
    #13
  14. Philipp Leitner wrote:
    >
    >> It doesn't, but it may help you prevent the exception. In some cases you
    >> could check for the condition that causes the exception, and prevent it
    >> from happening. It is most useful for things like incorrect parameters.

    >
    > ok, now I get what you meant; unfortunately this would be quite strange
    > (if not impossible) to do in my case since I heavily depend on member
    > variables.
    >
    > /philipp


    Its also not a great design choice, because now the derived class would
    have knowledge of what is good or bad data from its base class.

    You'd never want coupling that is this tight.
    Andrew McDonagh, Apr 17, 2006
    #14
  15. Philipp Leitner

    Tony Morris Guest

    "Philipp Leitner" <> wrote in message
    news:4443cbe1$0$11352$...
    > hi all,
    >
    > this may be a silly question, but is there actually any way to _overwrite_
    > a constructor of a superclass in Java?
    >
    > I have the following inheritance structure:
    >
    > "ProfileAdmin" inherits from "ProfileSearcher"
    >
    > both classes are almost identical, the main difference is that the
    > constructor of ProfileSearcher throws an exception in certain
    > circumstances, while ProfileAdmin should try to repair the problem in
    > these cases (with the reason that ProfileSearcher should be used on thin
    > clients, which are not capable of the cpu-heavy repair actions).
    >
    > My first idea would have been to just overwrite the constructor of
    > ProfileSearcher, but I quickly discovered that javac inserts an implicit
    > "super()" at the beginning of the subclasses' constructor (I really had no
    > clue about that in advance ...) :-(
    >
    > Any tips on how to solve this issue in a clean way?
    >
    > thx in advance,
    > Philipp
    >
    > --
    > Philipp Wolfgang Leitner, Bakk.rer.soc.oec.
    > 0225511
    > Vienna University of Technology
    >
    > "Ask five economists and you'll get five different explanations (six if
    > one went to Harvard).
    > -- Edgar R. Fiedler"


    You're referring to, I assume, a no-argument constructor.
    This is not the same thing as a default constructor, albeit common
    misconception.

    You're also experiencing a consequence of the inherent excess requirement
    (and subsequent requirment defect) that is implied by the semantics of Java
    (and all known OO languages) constructors. Live with it, fix it, or
    workaround it.

    ContractualJ (http://contractualj.com/):
    All constructors are declared private, and throw
    java.lang.UnsupportedOperationException, unless they are implicit
    constructors of anonymous classes. Exposing construction details (as Java
    constructor semantics implies) is not permitted.

    --
    Tony Morris
    http://tmorris.net/
    Tony Morris, Apr 18, 2006
    #15
  16. Philipp Leitner

    Chris Uppal Guest

    Oliver Wong wrote:

    > I was aware of the rule that "super()" has to be the first statement,
    > but I wasn't aware that a "try-catch" block "counts" as a statement.


    The idea is that the system doesn't "allow" you to see an object in an
    incompletely constructed state[*]. If the super-class's constructor has, in
    effect, said "No you can't create this object", then Java and the JVM won't let
    a subclass say "Bugger that! I'm going to create it /anyway/".

    ([*] I agree that the guards against this are a little leaky...)

    -- chris
    Chris Uppal, Apr 18, 2006
    #16
  17. Philipp Leitner

    Chris Smith Guest

    Chris Uppal <-THIS.org> wrote:
    > Oliver Wong wrote:
    >
    > > I was aware of the rule that "super()" has to be the first statement,
    > > but I wasn't aware that a "try-catch" block "counts" as a statement.

    >
    > The idea is that the system doesn't "allow" you to see an object in an
    > incompletely constructed state[*]. If the super-class's constructor has, in
    > effect, said "No you can't create this object", then Java and the JVM won't let
    > a subclass say "Bugger that! I'm going to create it /anyway/".


    Yep, and the problem of course is that a try/catch block is not used
    merely to ignore exceptions, but also to wrap them... which may be a
    quite sensible thing to want to do.

    In this case, though, it appears there's something wrong with the
    inheritance structure.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Apr 18, 2006
    #17
  18. Philipp Leitner

    Jeroen V. Guest

    You can avoid executing the code in the superconstructor by wrapping the
    superconstructor code with:


    if(this.getClass().getName().equals(com.xxx.yyy.ProfileSearcher){
    //constructor code
    }
    Jeroen V., Apr 18, 2006
    #18
  19. Philipp Leitner

    Jeroen V. Guest

    Jeroen V. wrote:
    > You can avoid executing the code in the superconstructor by wrapping the
    > superconstructor code with:
    >
    >
    > if(this.getClass().getName().equals(com.xxx.yyy.ProfileSearcher){
    > //constructor code
    > }


    should be:

    if(this.getClass().getName().equals("xxx.yyy.ProfileSearcher"){
    //constructor code
    }
    Jeroen V., Apr 18, 2006
    #19
  20. Philipp Leitner

    James McGill Guest

    On Tue, 2006-04-18 at 19:29 +0200, Jeroen V. wrote:
    > Jeroen V. wrote:
    > > You can avoid executing the code in the superconstructor by wrapping the
    > > superconstructor code with:
    > >
    > >
    > > if(this.getClass().getName().equals(com.xxx.yyy.ProfileSearcher){
    > > //constructor code
    > > }

    >
    > should be:
    >
    > if(this.getClass().getName().equals("xxx.yyy.ProfileSearcher"){
    > //constructor code
    > }


    How is there a "this" if the superconstructor hasn't been called?
    James McGill, Apr 18, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Aire
    Replies:
    3
    Views:
    465
    Mike Wahler
    Jan 25, 2004
  2. Replies:
    9
    Views:
    961
    Alf P. Steinbach
    Mar 6, 2006
  3. Replies:
    9
    Views:
    477
    Bo Persson
    Jan 5, 2007
  4. Generic Usenet Account
    Replies:
    10
    Views:
    2,226
  5. Mug

    constructor overwrite

    Mug, Feb 15, 2010, in forum: Python
    Replies:
    3
    Views:
    360
    Bruno Desthuilliers
    Feb 15, 2010
Loading...

Share This Page