[Soot-list] Extra athrow instruction in a finally block

Richard L. Halpert richardlhalpert at gmail.com
Thu Mar 6 15:48:04 EST 2008


The method a() could throw an Error, too.  Did you try compiling this code
with "catch(Throwable t)" instead?  If the compiler is smart, your athrow
might go away.  Otherwise, it might become unreachable code.

-Richard

On Thu, Mar 6, 2008 at 12:24 PM, <mbatch at cs.mcgill.ca> wrote:

> > That's because the finally block has to rethrow the exception that
> > caused it to execute (in case there was any).
>
> Exceptions do not cause a finally block to execute - they always execute
> no matter what.
>
> The catch block is implicitly protected by a try/catch of it's own which
> ensures that the finally always gets run, even if the code within the
> catch block throws its own exception. This is where the second try/catch
> (TRYCATCHBLOCK L0 L3 L4) in the bytecode is coming from.
>
> So - if the catch block throws its own exception, the bytecode stores the
> new exception, executes the finally block, and then loads the exception
> back up and throws it.
>
> Understandably, one might think that an empty catch block will never throw
> an exception, but there can be asynchronous exceptions, memory exceptions,
> etc.
>
> I hope this helps,
>
> Michael
>
>
>  On Thu, March 6, 2008 2:05 pm, Eric Bodden wrote:
>
> > On 06/03/2008, Alvin Yan <feiya200 at cs.uregina.ca> wrote:
> >
> >> Hmmm, no. For example a code piece:
> >> try{ a(); }catch(Exception e){
> >>
> >>
> >> }finally{
> >> System.out.println();
> >> }
> >>
> >>
> >> will be compiled to
> >>
> >> TRYCATCHBLOCK L0 L1 L2 java/lang/Exception
> >> TRYCATCHBLOCK L0 L3 L4
> >> L0 (0)
> >> LINENUMBER 8 L0
> >> ALOAD 0
> >> INVOKEVIRTUAL Test.a()V
> >> L1 (3)
> >> GOTO L5
> >> L2 (5)
> >> LINENUMBER 9 L2
> >> FRAME SAME1 java/lang/Exception
> >> ASTORE 1
> >> L3 (8)
> >> LINENUMBER 12 L3
> >> GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
> >> INVOKEVIRTUAL java/io/PrintStream.println()V
> >> GOTO L6
> >> L4 (12)
> >> LINENUMBER 11 L4
> >> FRAME SAME1 java/lang/Throwable
> >> ASTORE 2
> >> L7 (15)
> >> LINENUMBER 12 L7
> >> GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
> >> INVOKEVIRTUAL java/io/PrintStream.println()V
> >> L8 (18)
> >> LINENUMBER 13 L8
> >> ALOAD 2
> >> ATHROW
> >> L5 (21)
> >> LINENUMBER 12 L5
> >> FRAME SAME
> >> GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
> >> INVOKEVIRTUAL java/io/PrintStream.println()V
> >> L6 (25)
> >> LINENUMBER 14 L6
> >> FRAME SAME
> >>
> >>
> >> I'm just wondering why there is that ATHROW?
> >> Thanks a lot!
> >>
> >>
> >> Alvin
> >>
> >>
> >> --------------------------------------------------
> >> From: "Eric Bodden" <eric.bodden at mail.mcgill.ca>
> >> Sent: Thursday, March 06, 2008 8:24 AM
> >> To: "Alvin Yan" <feiya200 at cs.uregina.ca>
> >> Cc: <soot-list at sable.mcgill.ca>
> >> Subject: Re: [Soot-list] Extra athrow instruction in a finally block
> >>
> >>
> >>
> >>> You mean code like that?
> >>>
> >>>
> >>> try{ ...
> >>> } finally {
> >>> throw e; //(x) }
> >>>
> >>>
> >>> Certainly line (x) is an exit point for this method because an
> >>> exception *will* be thrown at this point. The try/finally construct
> >>> only guards the "try" part, not the "finally" part.
> >>>
> >>> Eric
> >>>
> >>
> >
> >
> > --
> > Eric Bodden
> > Sable Research Group
> > McGill University, Montréal, Canada
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
> >
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20080306/feb7916b/attachment.htm


More information about the Soot-list mailing list