exception dilema

[Dan Andrei]

Given the following code:
class MyException extends Exception{}
class TestExc6 {
public void m1() throws MyException
{throw new MyException();}
public void m2() throws RuntimeException
{throw new NullPointerException();}
public void aMethod() {
try
{
m1();
}
catch (MyException e)
{
m1();
}
finally
{
throw new RuntimeException(); //case (1)
//m2(); //case (2)
}
}

public static void main(String[] args) {
TestExc6 tc = new TestExc6();
tc.aMethod();
}
}
Now when I compile this code with case (1) it compiles, and its OK because the compiler notices that an exception is thrown in the finally clause, so
the exception rethrown in the catch clause is dropped so there is no need
for a throws clause in the header of the method...
as in public void aMethod() throws MyException, Right ?
Now if I comment case(1) in finally and add case(2) a call to m2() which throws also an unckecked exception I get a compile error saying:
"unreported exception MyException; must be caught or declared to be thrown
m1();"
Can someone explain me why, aren't the two caes basically the same
Thanx

[fethi makhlouf]

Hi DAN
That's ur code
--------------------------------------------------------------------------------
Given the following code:
class MyException extends Exception{}
class TestExc6 {
public void m1() throws MyException
{throw new MyException();}
public void m2() throws RuntimeException
{throw new NullPointerException();}
public void aMethod() {
try
{
m1();
}
catch (MyException e)
{
m1();
}
finally
{
throw new RuntimeException(); //case (1)
//m2(); //case (2)
}
}
____________________________________________

I think that th error occurs bnecause you are calling a method that throws an checked exception, and you should know, that calling such a method makes you obliged to handle the exception, even if you are inside a finally block!
have you ever seen that?
try{....}
catch(){.....}
finally{
.....
try{.......}
catch{.....}
}
in the first case you don't have problem 'cause the thrown exception is unchecked that's all!
Hope it's clear!

[Dan Andrei]

Please rAed the code carefully in both cases finally throws an UNCHECKED EXCEPTION !!!
PLEASE SOMEONE GIEV AN INSIGHT ON THIS ONE

[Joe Gilvary]

They're not basically the same to the compiler, because it doesn't look at all of the work in the m2() call and say, "Gee, this is always throwing a new RuntimeException, so the finally block overrides the call from inside the catch block." It says something more like, "The finally block does not explicitly throw an exception, so the possible exceptions in the catch block method invocations need to be declared."
You can read the code and "mentally inline" the m2() call inside the finally block, but the compiler doesn't. It sees a finally block that makes a method invocation, but doesn't "notice" what that method invocation must do.

Thanks,
Joe

[Dan Andrei]

well joe, first I had the same resoning BUT...
in catch block we have the same situation we have a call to a method m1() not an explicit throw new MyException().
So following this resoning it should NOT give a compile error...

[Ernest Friedman-Hill]

It's not the same. In one case, there's an exception being thrown from the finally block. In the other case, there's a method being called. Those two aren't the same at all, are they?
Now, granted, the method might throw an exception which masked the other exception -- but it might not, as far as the compiler knows. The compiler has to cover all the bases. "Might" isn't good enough.

[Dan Andrei]

you're right Ernst, however in the catch block we have the same situation ) a call to a method m1())
then why the compiler complain that exception thrown by m1() must be caught or thrown in the method clause.
This is my question, I think its an inconsistency on the part of the compiler

[S Goyal]

When the code is complied
in case 1 and 2 - TestEx6.java:23: unreported exception MyException; must be caught or declared to be thrown
which is correct. myexception is never caught! If code is chaned to

  public void aMethod()  throws MyException 

it works fine in case 1 and 2 both. Case 2 works becos runtime exception does not need to be caught or put in throws clause

[Dan Andrei]

Goyal
in case 1 a get no compil error
please read crefully again my first post

[stevens sun]

I did test on Jbuilder7.0 JDK1.4.
CASE 1:
public void aMethod()
{
try
{
m1();
}
catch (MyException e)
{
m1();
}
finally
{
throw new RuntimeException(); //case (1)
//m2(); //case (2)
}
}
CASE 2:
public void aMethod()
{
try
{
m1();
}
catch (MyException e)
{
m1();
}
finally
{
//throw new RuntimeException(); //case (1)
m2(); //case (2)
}
}
Both case 1 and case 2 got the message:
"test.java": Error #: 360 : unreported exception: hellojava.MyException; must be caught or declared to be thrown at line 55, column 13

[C. Nimo]

Hi.
I think the explanation lies in the way compilers are structured (and that's probably why the last post got the message both times).
Most of the compilers see that the catch{} clause might throw an exception, and look for a remedy to that situation - the remedy is the existence of a finally() clause.
If you have a finally{} clause it means that someone else is taking care of any checked exception thrown in catch{}, and therefore the explanation of another exception that's always thrown there satisfies the compiler, and your first case gets compiled (with a warning, though).
In the second case, however, the compiler knows that there's an exception that might be raised in the catch{} clause, but no one to handle it (the finally doesn't do anything with it, because m2 "might" throw an exception) - and therefore the second case does not compile.
If you take your original code and remove the finally{} clause, you will see that you get the error message on the call to m1() that's inside the catch{} clause.
Hope this helps -
Nimo.