2017-07-26 97 views
1

給出一個簡單的try-catch-終於方法:LocalVariableTable中缺少什麼?

public void t() { 
    try { 
     f1(); 
    }catch(Exception e) { 
     f2(); 
    }finally { 
     f3(); 
    } 
} 

隨着 「javac的-g」,它編譯成:

public void t(); 
    descriptor:()V 
    flags: ACC_PUBLIC 
    Code: 
stack=1, locals=3, args_size=1 
    0: aload_0 
    1: invokespecial #15     // Method f1:()V 
    4: goto   26 
    7: astore_1 
    8: aload_0 
    9: invokespecial #18     // Method f2:()V 
    12: aload_0 
    13: invokespecial #21     // Method f3:()V 
    16: goto   30 
    19: astore_2 
    20: aload_0 
    21: invokespecial #21     // Method f3:()V 
    24: aload_2 
    25: athrow 
    26: aload_0 
    27: invokespecial #21     // Method f3:()V 
    30: return 
Exception table: 
    from to target type 
     0  4  7 Class java/lang/Exception 
     0 12 19 any 
LineNumberTable: 
    line 7: 0 
    line 8: 4 
    line 9: 8 
    line 11: 12 
    line 10: 19 
    line 11: 20 
    line 12: 24 
    line 11: 26 
    line 13: 30 
LocalVariableTable: 
    Start Length Slot Name Signature 
     0  31  0 this Lsample/Sample; 
     8  4  1  e Ljava/lang/Exception; 
StackMapTable: number_of_entries = 4 
    frame_type = 71 /* same_locals_1_stack_item */ 
    stack = [ class java/lang/Exception ] 
    frame_type = 75 /* same_locals_1_stack_item */ 
    stack = [ class java/lang/Throwable ] 
    frame_type = 6 /* same */ 
    frame_type = 3 /* same */ 

通知當地人= 3,但也有隻有兩個項目LocalVariableTable。字節碼行19(astore_2)和24(aload_2)表示第三個局部變量確實存在。

問題是:什麼是第三個局部變量,以及爲什麼它在LocalVariableTable中被遺漏?

回答

1

第三個局部變量是finally塊的實現細節。在你的try/catch拋出一個變量的情況下,它必須暫時存儲這個異常,因此它可以在重新拋出之前調用f3(),這就是插槽2正在做的事情。

+0

有趣的設計。如果在調用'f3()'之前,變量僅留在操作數堆棧上,它是否也能工作? (這可能會增加堆棧的最大深度?) – dejvuth

+0

在這種情況下,第三個局部變量應該是Throwable類型嗎?但爲什麼它不會出現在LocalVariableTable中? – ziyi

+0

在這種情況下,它可能已經留在操作數堆棧中,但Javac的代碼根據各種原因試圖儘可能避免這種情況。如果我不得不猜測它爲什麼不出現在表中,那是因爲它不對應於任何源級別變量。 LocalVariableTable僅用於調試。 – Antimony