Exceptions

[arawin99]

This is what I had coem up with to check the flow in a nested try catch block
here I have a nested try catch block in the methodA() where in the inner try catch block a division by zero exception (ArithmeticException) is generated. but a matching catch is found in the outer catch block . I am doing a return statement in each of the finally block . Although An exception has been generated and a matching catch block (outer) is also there , STILL THIS CODE DOESNOT ENTER INTO THE CATCH BLOCK . (probably coz of the return in the first finally block ) I was under the impression that once an exception has been ghenerated it shud be caught somewhere .
If I try running this piece of code it doesnot execute any of the catch blocks . I want to know WHY???

class nested {
public int methodA(int i , int j){
try{
System.out.println("Inside outer try");
try{
System.out.println("Inside inner try");
System.out.println("before executing  i and j are " + i + " " + j );
i = i /j;
}catch(ArrayIndexOutOfBoundsException e){
System.out.println("Inside inner catch ");
}finally{
System.out.println("Inside inner finally ");
 return i ;
}
    }catch(ArithmeticException e){
System.out.println("Inside outer catch and Exception caught :-" + e);
}
    finally{
System.out.println("Inside outer finally ");
return i ;
}
}
public static void main (String args[]){
int i = 10 , j = 0 ;
nested mynested = new nested();
try{
System.out.println("Inside main try ");
i = mynested.methodA(i,j);
}catch (Exception e){
System.out.println("Inside main catch");
}
finally{
System.out.println("Inside main finally");
}
}
}

Please help
regards
arawin
[This message has been edited by maha anna (edited December 28, 2000).]

[Jane Griscti]

Arawin,
Please read the JavaRanch name policy and re-register with a name which complies with the rules.
Your co-operation would be appreciated.
Thanks
------------------
Jane
The cure for boredom is curiosity.
There is no cure for curiosity.
-- Dorothy Parker

[maha anna]

Arawin,
The 'return i;' statement in this part of your code is the culprit. Which means , you want to return from this method at any cost. So ONLY finally in outer try..catch..finally will be executed.
Just comment this statement 'return i' in this section, now your outer catch for ArithmeticException will be executed.
Also please register with your 'firstName lastName'.

finally{
   System.out.println("Inside inner finally ");
  //return i ; //Just comment and see.
}

[This message has been edited by maha anna (edited December 28, 2000).]

[Arvind Kini]

Hi all ,
I am sorry for voilating the rules !! I am no longer arawin99 now .
Thanx for reminding !
and BTW maha , U mean if theres the return clause in finally then the exception is LOST ?
please clarify
thanks
Arvind

[maha anna]

Arvind,
Thanks for re-registering.
Yes. When there is a return statement in a finally {..} block, execution control is returned back to the calling method with any exceptions thrown / not handled at this point of return statement.
Since the finally block is always executed, for any outer blocks of this inner finally {...} block, after executing, inner finally, just before leaving this method, outer finally also is executed.
regds
maha anna

[rajesh batchu]

hi everybody,
this is a good logic.
i have a small doubt.as per the answer given by maha anna ,after the execution of inner finaaly and outer finally the uncught arithmetic exception is passed to the calling method. i.e the control isin the main try.now the catch should execute??? then why the finally of mail is executing..please give me reply.
my doubt is that troubling "return i" making the methodA() toreturn OR main() to return.

[Arvind Kini]

what I cud understand from this is that the exception thrown inside the inner try is "CAUGHT" by the outer catch block , but since finally of every try /catch bolck "SHOULD" execute soon after the control comes out from that particular try/catch block(inner in our case) , the control "GOESBACK" to the finally clause and then comes across the return statement which returns it to the main method, thus preventing it from going in the "CATCH " block of outer.
Since our exception is already "CAUGHT" inside the outer try of methodA() , now no exception is actually there which is "UNHANDLED", which is seen from the fact that catch block of main() is not executed.
Please correct me if I have messed up on this
regards
arvind

[maha anna]

Arvind,
To make our discussions easier, I just print the output of our program in both cases with and without the 'return i;' statement in 'inner finally' block.

// with return i in inner fianlly block
Inside main try 
Inside outer try
Inside inner try
before executing  i and j are 10 0
Inside inner finally 
Inside outer finally 
Inside main finally
// WITHOUT return i in inner fianlly block
Inside main try 
Inside outer try
Inside inner try
before executing  i and j are 10 0
Inside inner finally 
Inside outer catch and Exception caught :-java.lang.ArithmeticException: / by zero
Inside outer finally 
Inside main finally

What happens is , when 10/0 is calculated, an 'ArithmeticException' is thrown. But there is no catch block for this exception, in inner try..catch..finally block. So before trying to the next level [ in our case, which is the next immediate surrounding block, which is outer try..catch..finally block ] , finally of inner try..catch...finally is executed.
So what happens here is the 'println' statement is executed. UPTO this point the ArithmeticException is carried over. But when JVM sees the return i statement, the cause of this abnormal completion of inner 'try block' which is Arithmethic Exception is DROPPED. The reason for this DROPPING OF CAUSE (Arithmetic Exception) is again 'abnormal completion of finally block' of this inner try..catch..finally block , because of the 'return i' statement.
Reference from JLS :
Whenever there is a return statement in a chunk of statements, the execution of such statements are said to complete abruptly
So bottom line is,
1. If execution of the try block completes abruptly due to Arithmetic Exception (the cause)
2. There is no catch block for this ArithmeticException
3.The inner finally block completes abruptly for reason 'return i' statement , so the inner try statement completes abruptly for cause 'return i' statement (and previous cause 'ArithmeticException' is discarded).
Also Arvind,
I give you the exact JLS portion which clearly says this above concept. Please read it very carefully. It clearly says the reason, why our output is like this.
References from JLS:
14.18.2 Execution of try-catch-finally
--------------------------------------- http://java.sun.com/docs/books/jls/html/14.doc.html#236653

If the run-time type of V is not assignable to the parameter of any catch clause 
of the try statement, then the finally block is executed. Then there is a choice: 
If the finally block completes normally, then the try statement completes abruptly 
because of a throw of the value V. 
<font color=red>
If the finally block completes abruptly for reason S, then the try statement completes 
abruptly for reason S (and the throw of value V is discarded and forgotten). </font>

14.1 Normal and Abrupt Completion of Statements
-----------------------------------------------
http://java.sun.com/docs/books/jls/html/14.doc.html#5894

An abrupt completion always has an associated reason, which is one of the following:
.
.
A return with no value 
A return with a given value 
A throw with a given value, including exceptions thrown by the Java Virtual Machine  

14.15 The return Statement
-------------------------- http://java.sun.com/docs/books/jls/html/14.doc.html#6767

It can be seen, then, that a return statement always completes abruptly.

Did all above information convince you ?
regds
maha anna

[This message has been edited by maha anna (edited December 30, 2000).]

[Arvind Kini]

thanx MA! also I just downloaded the JLS . its pretty HUGE and the wordings there are a bit confusing. Do ya suggest a thorough read of that ?
Any comments wud be highly appreciated
regards
Arvind

[George Toronto]

Logical and Clear answer. Thanks. Maha Anna.

[maha anna]

Arvind,
JLS is generally little hard to understand. Some chapters are easier to understand in first read itself. Some others need atleast 2 tries. The hard work really pays off. But it depends. Trying to understand the examples alone in JLS itself will boost our knowledge. We need not write examples for each and every if..else..if...else conditions specified in JLS.
But we atleast should know where the related references are, whenever we get doubts like this.
regds
maha anna