[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bcel-user
Subject:    RE: Please help me regarding finally block
From:       "Koduru, Rajendra Kumar Reddy" <rajendra.kumar.reddy.koduru () sap ! com>
Date:       2005-02-05 19:35:11
Message-ID: 73DFF891F8024B48AD56B594C4C5038A0196BDF3 () dewdfe23 ! wdf ! sap ! corp
[Download RAW message or body]

Hi Andrew,

	Thank you for clarifying my questions

Thank you
Reddy




>-----Original Message-----
>From: Andrew Huntwork [mailto:ash@huntwork.net] 
>Sent: Freitag, 4. Februar 2005 22:15
>To: BCEL Users List
>Subject: Re: Please help me regarding finally block
>
>
>Koduru, Rajendra Kumar Reddy wrote:
>> 		//  IN THE FOLLOWING SNIPPET OF CODE, CALL TO
>> SUBROUTINES ARE INSERTED AND ALL THE TARGETS OF RETURN 
>INSTRUCTIONS ARE
>> CHANGED
>
>returns are not targeters.  what you're redirecting below are things 
>that target return.  you want things that jump directly to the 
>return to 
>jump to the jsr instead.  that way the jsr will be executed 
>whenever the 
>return is executed.
>
>> 
>> 		Collection<JSR> jsrs = new ArrayList<JSR>();
>> 		for (Iterator i = il.iterator(); i.hasNext(); ) {
>> 			InstructionHandle ih =
>> (InstructionHandle)i.next();
>> 
>> 			if (ih.getInstruction() instanceof RETURN) {
>> 				JSR jsr2 = new JSR(null);
>> 				jsrs.add(jsr2);
>> 				InstructionHandle n = il.insert(ih,
>> jsr2);
>> 							
>> 				il.redirectBranches(ih, n);
>> 			}
>> 		}
>> 
>> 		// END OF ABOVE UNDERSTANDING. AM I CORRECT ??
>> 
>> 		
>> 		
>> 		InstructionHandle h1 = il.append(new ASTORE(0)); // AT
>> THE CURRENT SITUATION, WHAT IS ON THE TOP OF STACK AND WHY IS IT
>> STORED??
>
>you are inserting a try/catch around the entire original function to 
>implement finally.  h1 is the handler.  an exception handler 
>is executed 
>with the Throwable on the stack, and that's what you're 
>storing in lv 0.
>
>> 
>> 		JSR jsr = new JSR(null);
>> // WHY A SUBROUTINE CALL IS DONE HERE??? 
>
>the basic idea of finally is that you insert one subroutine 
>that will be 
>executed before the function exits by any path.  the possible 
>exit paths 
>are:  all of the return instructions and an uncaught 
>exception.  we took 
>care of calling the subroutine from the return instructions 
>above.  now 
>we're taking care of exits via uncaught exceptions.  this 
>block catches 
>all exceptions, calls the subroutine, and re-throws the exception.
>
>> 
>> 		jsrs.add(jsr);
>> 		il.append(jsr);
>> 
>> 		InstructionHandle h2 = il.append(new ALOAD(0));	  //
>> REFLECTS THE ABOVE STORE OPERATION; SO WHAT IS ACTUALLY IN THIS NOW??
>
>here we load the exception we caught and stored at the 
>beginning of the 
>block and re-throw it
>
>> 
>> 		il.append(new ATHROW());
>> // I THINK IT IS TO RETHROW THE EXCEPTION IF AN EXCEPTION ARISES
>
>yep
>
>> 
>> 		InstructionHandle handler = il.append(new ASTORE(1)); //
>> STORES THE EXCEPTION VARIABLE
>
>no.  a subroutine is executed with the return address on the stack. 
>this is a special jvm type.  that's what we're storing here.
>
>> 
>> 		// I WILL APPEND AN PRINTLN STATEMENT HERE 
>
>good.  this is the right place for it.
>
>> 
>> 		il.append(new RET(1));
>> // RETURNING FROM SUBROUTINE, BUT DOESNT THE INDEX OF RET START AT 0
>
>the argument to ret is a local variable index containing a return 
>address.  Thus, jsr and ret are assymetric.  one puts a return address 
>onto the stack, and the other loads it from a local variable.  
>whatever.
>
>> 
>> 		for (JSR j : jsrs) {
>> 			j.setTarget(handler);
>> 		}	
>> 
>> 		mg.addExceptionHandler(start, end, h1, null);	//
>> DOESNT THE EXCEPTION HANDLER START AT HANDLE handler(which is just 3
>> lines above in this code)
>
>see above re:  catching and re-throwing all uncaught exceptions.
>
>> 
>> 		il.setPositions(true);
>> //  IS THIS NECESSARY ??
>
>i don't know, but just to be safe i'd at least call il.setPositions();
>
>> 	}
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>> 
>> 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]