• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

exception dilema

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please rAed the code carefully in both cases finally throws an UNCHECKED EXCEPTION !!!
PLEASE SOMEONE GIEV AN INSIGHT ON THIS ONE
 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Goyal
in case 1 a get no compil error
please read crefully again my first post
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic