RR#99

[Steven YaegerII]

If method A declares that it throws an exception and method B calls method A, then method B must ALWAYS declare the same exception...? (t/f)
False. Method B does not have to declare the exception if it handles it by providing an appropriate catch(), OR if method A's exception is a runtime exception.
I confirmed the answer by using a runtime exception in the code below, but questions arose when I used a checked exception...

public class RR
{
    int x;
    RR( int num )
    {
        x = num;
    }
    int methodA()    // throws ClassNotFoundException    // line 10
    {
        return x + 10;
    }
    int methodB()    // throws ClassNotFoundException    // line 15
    {
        int y = methodA();    // line 17
        return y + 1;
    }
    public static void main( String[] args )
    {
        RR rr1 = new RR( 100 );
        System.out.print( rr1.methodB() );    // line 25
RR rr2 = new RR( 37 );
System.out.print( rr2.methodB() );
    }
}

No big deal, it outputs 111 48. Second, in line 10, I do: int methodA() throws ClassNotFoundException and get an error at line 17 - "java.lang.ClassNotFoundException must be caught, or it must be declared in the throws clause of this method."
int y = methodA();
^
In the first case it compiles fine, though I thought in line 17 that the statement int y = methodA(); would be treated as seperate from int methodA()'s declaration in line 10, sort've like a local variable. WHY THE ERROR WITH THE SECOND TRY??
Third, in lines 10 & line 15, I make both method declarations throw the exception and I get the same type error, only this time in line 25:
System.out.print( rr1.methodB() );
^
WHAT'S THE REASON FOR THIS CRAZINESS??
ARE RUNTIME EXCEPTIONS OF TYPE RuntimeException & Error, WHILE ALL OTHERS COMPILE TIME (checked) EXCEPTIONS??

[Scott Appleton]

Steven, I'm assuming that when you say "Second try", you mean that you're unremming the throws statements, whereas all statements in the first try are remmed as you have posted.
When you unrem line 10, you're asserting that methodA() throws a checked exception. Therefore, all statements which call methodA() (e.g., line 17) must catch the exception or fail to compile.
The same applies to unremming line 15 and the statement call in line 25.

[Steven YaegerII]

Oh, O.K., I think I vaguely remember something about that.
Is the rule that "whenever you call a method that throws a checked exception, you must provide catching code" ?
Also, last night I formulated that "runtime exceptions are classes or subclasses of RuntimeException or Error, while all others are checked exceptions". Is this safe to keep assuming?

[Mapraputa Is]

Is the rule that "whenever you call a method that throws a checked exception, you must provide catching code" ?
Yes. Or, if a calling method doesn�t want to catch a checked exception, it must declare this exception in its own throws clause. Because now a calling method itself will throw this exception (it is called exception propagation)
Also, last night I formulated that "runtime exceptions are classes or subclasses of RuntimeException or Error, while all others are checked exceptions". Is this safe to keep assuming?
It seems that you use a little wrong terms There is no division between "runtime" and "checked" exceptions, all exceptions and errors are thrown at run-time! The division is between "checked" and "unchecked" exceptions and, I believe, the difference exists on compilation stage only. It is the compiler, who will check if certain exceptions (called checked) are properly dealt with. It happened that checked exceptions are descendants of the class named "Exception" and unchecked � of the class "RuntimeException", but these names are rather unfortunate and misleading. Objects or both classes are exceptions and objects of both classes are run-time exceptions!
To make it clear:
Unchecked exceptions: subclasses of Error and RuntimeException.
Checked exceptions: subclasses of Throwable but not subclasses of Error and RuntimeException. Subclasses of the Exception class fit this definition and are checked.

[Steven YaegerII]

Thanks for setting me straight on that, Mapraputa. I do seem to distort meanings alot. I am very grateful to JavaRanch for that reason, and many others, cause it is about the only human interaction I can get, concerning Java.