extraño entrada de la tabla de excepción producida por javac de Sun

Question

Teniendo en cuenta este programa:

class Test { 
    public static void main(String[] args) { 
     try { 
      throw new NullPointerException(); 
     } catch (NullPointerException npe) { 
      System.out.println("In catch"); 
     } finally { 
      System.out.println("In finally"); 
     } 
    } 
} 

de Sun javac (v 1.6.0_24) produce el siguiente código de bytes:

public static void main(java.lang.String[]); 

     // Instantiate/throw NPE 
    0: new  #2;   // class NullPointerException 
    3: dup 
    4: invokespecial #3; // Method NullPointerException."<init>":()V 
    7: athrow 

     // Start of catch clause 
    8: astore_1 
    9: getstatic  #4; // Field System.out 
    12: ldc  #5;   // "In catch" 
    14: invokevirtual #6; // Method PrintStream.println 
    17: getstatic  #4; // Field System.out 

     // Inlined finally block 
    20: ldc  #7;   // String In finally 
    22: invokevirtual #6; // Method PrintStream.println 
    25: goto 39 

     // Finally block 
     // store "incomming" exception(?) 
    28: astore_2 
    29: getstatic  #4; // Field System.out 
    32: ldc  #7;   // "In finally" 
    34: invokevirtual #6; // Method PrintStream.println 

     // rethrow "incomming" exception 
    37: aload_2 
    38: athrow 

    39: return 

Con la tabla siguiente excepción:

Exception table: 
    from to target type 
    0  8  8 Class NullPointerException 
    0 17 28 any 
    28 29 28 any 

Mi pregunta es: ¿Por qué incluye esa última entrada en la tabla de excepciones?

lo que tengo entendido, que básicamente dice "si el astore_2 se produce una excepción, lo coge y vuelva a intentar la misma instrucción".

Dicha entrada se produce incluso con vacío try/catch/finally cláusulas tales como

try {} catch (NullPointerException npe) {} finally {} 

---

Algunas observaciones

• Eclipse compilador no produce ninguna entrada tales tabla de excepciones
• La especificación de JVM no documenta ninguna excepción de tiempo de ejecución para the astore instruction.
• Sé que es legal que la JVM arroje VirtualMachineError para cualquier instrucción. Supongo que la entrada peculiar evita que dichos errores se propaguen desde esa instrucción.

Answer 1

Existen solo dos explicaciones posibles: el compilador contiene un error o está colocando un tipo de marca de agua por motivos desconocidos.

Esa entrada es ciertamente falsa porque cualquier excepción lanzada por un bloque finally debe enviar el flujo de ejecución al manejador de excepción externo o finalmente al bloque, pero nunca "ejecutar nuevamente" el mismo bloque finally.

Además, una buena evidencia de que es un error/marca de agua, es el hecho de que Eclipse (y tal vez otros compiladores de Java) no generan dicha entrada, y aún así las clases generadas por Eclipse funcionan bien en la JVM de Sun.

Dicho esto, esta publicación es interesante porque parece que el archivo de clase es válido y verificado. Si fuera un implementador de JVM, ¡ignoraría esa entrada y llenaría un error para Sun/Oracle!

Answer 2

Según entiendo, la segunda entrada de la tabla de excepción es la cláusula catch all implícita añadida por el compilador para cubrir cualquier excepción/error arrojado en el cuerpo o los manejadores catch y la tercera entrada es la guardia en esa captura implícita forzar el flujo a través de la ejecución finalmente.

Answer 3

Si examina el código fuente de OpenJDK 7, me atrevo a adivinar la razón de que duran 28 29 28 any entrada de la tabla de excepción se debe a que el código que maneja el código de bytes astore (ver code a partir de la línea 1871) puede lanzar una java.lang.LinkageError excepción si el valor extraído de la pila del operando no es un tipo returnAddress o reference (consulte la especificación de la máquina virtual Java para astore) y quiere que esta condición de error aparezca en el seguimiento de la pila.

En el caso de que hay un mal tipo de operando en la pila de operandos, la JVM borrar la pila de operandos (deshacerse de ese mal operando), poner un LinkageError en la pila de operandos, y ejecutar el código de bytes astore de nuevo, esta vez ejecutando con éxito el bytecode astore usando una referencia de objeto LinkageError JVM. Consulte la documentación de athrow para obtener más información.

sospecharía en gran medida la causa de lanzar una LinkageError durante astore procesamiento se debe a la complexities JSR/RET subroutines introducir en la verificación de código de bytes (OpenJDK cambia 6878713, 6932496 y 7020373 son evidencia reciente de JSR 's continuó complejidad; I' m sure Sun/Oracle tiene otras pruebas de código cerrado que no estamos viendo en OpenJDK). El cambio OpenJDK 7020373 usa LinkageError para validar/invalidar los resultados de la prueba.