Java exceptions and function overriding.

[Razvan]

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

 

[VisionSet]

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

 

[Razvan]

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

 

[Babu Kalakrishnan]

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

 

[Tor Iver Wilhelmsen]

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.

 

[Razvan]

How about the reverse ? If the function from the superclass does not

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

 

[John C. Bollinger]

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
(e-mail address removed)

 

[Andrew Thompson]

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. ]

 

[P.Hill]

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

 

[Andrew Thompson]

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'. ]