Java exceptions and function overriding.

Discussion in 'Java' started by Razvan, Aug 30, 2004.

  1. Razvan

    Razvan Guest

    Hi !





    I am just trying to understand how exceptions must be specified on
    overriden functions. Take a look at the following code:


    import java.io.IOException;

    class CBase
    {
    public static int testX() throws RuntimeException { return 1;}
    public static int testX2() throws IOException { return 1;}
    }

    public class CDummy extends CBase
    {
    public static void main(String args[])
    {
    }

    public static int testX() throws IndexOutOfBoundsException { return
    2;}
    //public static int testX2() throws Exception { return 1;}
    }



    I understand that the overriden functions can throw only exceptions
    that are derived from the exception thrown by the function from the
    superclass. Can somebody explain why we have this restriction ? Does
    it matter if the exception is checked or not ?

    How about the reverse ? If the function from the superclass does not
    throw anything, what can be said about the functions that override it
    ?



    Regards,
    Razvan
     
    Razvan, Aug 30, 2004
    #1
    1. Advertising

  2. Razvan

    VisionSet Guest

    "Razvan" <> wrote in message
    news:...
    >
    > I am just trying to understand how exceptions must be specified on
    > overriden functions. Take a look at the following code:
    >
    > import java.io.IOException;
    >
    > class CBase
    > {
    > public static int testX() throws RuntimeException { return 1;}
    > public static int testX2() throws IOException { return 1;}
    > }
    >
    > public class CDummy extends CBase
    > {
    > public static void main(String args[])
    > {
    > }
    >
    > public static int testX() throws IndexOutOfBoundsException { return
    > 2;}
    > //public static int testX2() throws Exception { return 1;}
    > }
    >
    >
    >
    > I understand that the overriden functions can throw only exceptions
    > that are derived from the exception thrown by the function from the
    > superclass. Can somebody explain why we have this restriction ?

    Because all you may know about an object is its super type.
    So you mustn't get any nasty shocks about the exceptions it throws when you
    just have the superclass docs to refer to.

    > Does it matter if the exception is checked or not ?


    Yes, it matters, since RuntimeExceptions are not explicitly declared, except
    in the documentation (and it really should be documented).
    Then any RuntimeException can be thrown in super or sub regardless of any
    codeing.

    A subclass may extend the behaviour of the superclass, but the super class
    should still describe the subclass perfectly, just in a more general way.
    If the subclass goes and throws a different exception then it breaks that.
    It takes a bit of getting used to, generalization seems to be upside down at
    first.
    >
    > How about the reverse ? If the function from the superclass does not
    > throw anything, what can be said about the functions that override it
    > ?


    The subclass may then only throw RuntimeExceptions

    --
    Mike W
     
    VisionSet, Aug 30, 2004
    #2
    1. Advertising

  3. Razvan

    Razvan Guest

    Hi,


    Why you can throw some exceptions whenever you feel like while with
    other exceptions you cannot do the same ?

    Since RuntimeExceptions can be thrown anywhere, the code that handles
    the base class will be taken by 'surprise' anyway by some subclass
    that throws RuntimeExceptions. Whether you will throw a checked or
    unchecked exception
    should not matter since the code handling the base class has not
    anticipated that situation anyway.

    OTOH throwing any exception anywhere is more flexible. Why this
    trade-off was made ?



    Regards,
    Razvan
     
    Razvan, Aug 31, 2004
    #3
  4. Razvan wrote:
    >
    > Why you can throw some exceptions whenever you feel like while with
    > other exceptions you cannot do the same ?
    >


    Refer to the Java Language Specification Second Edition - section 11 for the
    full rationale behind why designers of the Java language chose to bifurcate
    exceptions into two types.

    BK
     
    Babu Kalakrishnan, Aug 31, 2004
    #4
  5. Babu Kalakrishnan <> writes:

    > Refer to the Java Language Specification Second Edition - section 11 for the
    > full rationale behind why designers of the Java language chose to bifurcate
    > exceptions into two types.


    The C# language is strangely schizophrenic this way: The designers
    decided you don't need to declare ANY exception throws, very nice of
    them. (In effect, all exceptions are RuntimeExceptions.)

    However, the language is more stringent than Java in other respects,
    like explicit method "override"/"new" keywords, no switch fallthrough
    etc.
     
    Tor Iver Wilhelmsen, Sep 1, 2004
    #5
  6. Razvan

    Razvan Guest

    > > How about the reverse ? If the function from the superclass does not
    > > throw anything, what can be said about the functions that override it
    > > ?

    >
    > The subclass may then only throw RuntimeExceptions


    It can only throw RuntimeException because they are NOT
    checked. But if that is true then it means that it can also throw
    Error exceptions because they are not checked either.




    Regards,
    Razvan
     
    Razvan, Sep 8, 2004
    #6
  7. Razvan wrote:

    >>>How about the reverse ? If the function from the superclass does not
    >>>throw anything, what can be said about the functions that override it
    >>>?

    >>
    >>The subclass may then only throw RuntimeExceptions

    >
    >
    > It can only throw RuntimeException because they are NOT
    > checked. But if that is true then it means that it can also throw
    > Error exceptions because they are not checked either.


    Errors are not Exceptions at all, although Errors and Exceptions are
    both Throwables. You are correct, however, that Errors never have to be
    declared (although they can be) and are not checked. In principal, any
    particular method may throw any RuntimeException or Error at any time
    during its execution. It is rarely useful to worry about whether or not
    a method will throw an Error, however, as those are intended for
    inherently unrecoverable program conditions. If your program throws one
    then there is nothing you can do about it except fix the program.


    John Bollinger
     
    John C. Bollinger, Sep 8, 2004
    #7
  8. On Wed, 08 Sep 2004 08:52:47 -0500, John C. Bollinger wrote:

    > It is rarely useful to worry about whether or not
    > a method will throw an Error, however, as those are intended for
    > inherently unrecoverable program conditions. If your program throws one
    > then there is nothing you can do about it except fix the program.


    Your second sentence clashes with your first..
    I agree with the first.

    Take this example in a simple SplashScreen
    that I wrote recently.
    [ Based on Roy Ratcliffe's 'SplashScreen.java
    1.1 03-Jan-04' (search the c.l.j.* archives
    for further info..), but in this section I
    diverge from his version ]

    public class SplashFrame extends Frame
    implements ImageObserver, Runnable {

    SplashFrame() {
    ....
    try {
    ...
    setAlwaysOnTop(true); // defined in 1.5
    // we are running 1.5+
    alwaysOnTop = true;
    } catch (java.lang.NoSuchMethodError e) {
    setTitle("Splash Screen");
    }
    ....
    }

    My version is 1.1 compatible, the 'alwayOnTop'
    flag is used later to determine if it is
    necessary to start a thread to keep bringing
    the splash screen to the front.

    I would prefer to use setAlwaysOnTop, but
    I can get almost everything it provides by
    alternate means.

    Business as usual, it is simply a matter
    of degrading gracefully to older JVM's.

    [ Oh, and yes John. I realise you *do* appreciate
    that. I just thought an example might help any
    newbs (..what are they doing on c.l.j.p.!) who
    might stumble across the thread. ]

    --
    Andrew Thompson
    http://www.PhySci.org/ Open-source software suite
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.1point1C.org/ Science & Technology
     
    Andrew Thompson, Sep 8, 2004
    #8
  9. Razvan

    P.Hill Guest

    Andrew Thompson wrote:

    > On Wed, 08 Sep 2004 08:52:47 -0500, John C. Bollinger wrote:
    >>It is rarely useful to worry about whether or not
    >>a method will throw an Error, [...] If your program throws one
    >>then there is nothing you can do about it except fix the program.

    >
    > Your second sentence clashes with your first..
    > I agree with the first.
    >
    > } catch (java.lang.NoSuchMethodError e) {
    > setTitle("Splash Screen");
    > }


    Okay, Andy you win todays prize for finding a
    useful Error to catch and recover.

    -Paul
     
    P.Hill, Sep 8, 2004
    #9
  10. On Wed, 08 Sep 2004 12:13:00 -0700, P.Hill wrote:

    > Okay, Andy you win todays prize for finding a
    > useful Error to catch and recover.


    I hope it's a T-Shirt, otherwise I might
    have to actually do a load of washing.

    [ And ..Paul, my name is 'Andrew'. ]

    --
    Andrew Thompson
    http://www.PhySci.org/ Open-source software suite
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.1point1C.org/ Science & Technology
     
    Andrew Thompson, Sep 8, 2004
    #10
    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. Ahmed Moustafa
    Replies:
    5
    Views:
    30,102
    Chris Smith
    Jul 14, 2004
  2. Paul Miller
    Replies:
    3
    Views:
    1,049
    Alex Martelli
    Nov 12, 2003
  3. Replies:
    2
    Views:
    350
    Tris Orendorff
    Nov 13, 2006
  4. Replies:
    3
    Views:
    631
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    699
Loading...

Share This Page