File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes exception dilema Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "exception dilema" Watch "exception dilema" New topic
Author

exception dilema

Dan Andrei
Ranch Hand

Joined: Jan 21, 2004
Posts: 92
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


"Did anyone understand what I have just explained? ... because I did not!"
fethi makhlouf
Ranch Hand

Joined: Feb 16, 2004
Posts: 50
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!


SCJP 1.4
Dan Andrei
Ranch Hand

Joined: Jan 21, 2004
Posts: 92
Please rAed the code carefully in both cases finally throws an UNCHECKED EXCEPTION !!!
PLEASE SOMEONE GIEV AN INSIGHT ON THIS ONE
Joe Gilvary
Ranch Hand

Joined: May 11, 2001
Posts: 152
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
Ranch Hand

Joined: Jan 21, 2004
Posts: 92
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Dan Andrei
Ranch Hand

Joined: Jan 21, 2004
Posts: 92
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
Greenhorn

Joined: Oct 28, 2002
Posts: 27
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

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
Ranch Hand

Joined: Jan 21, 2004
Posts: 92
Goyal
in case 1 a get no compil error
please read crefully again my first post
stevens sun
Greenhorn

Joined: Mar 22, 2004
Posts: 4
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
Ranch Hand

Joined: Mar 23, 2004
Posts: 82
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: exception dilema