Seltsamer Ausnahmetabelleneintrag, der von Javac von Sun erzeugt wurde

Angesichts dieses Programms:

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");
        }
    }
}

Sonne javac (v 1.6.0_24) erzeugt den folgenden Bytecode:

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

Mit folgender Ausnahmetabelle:

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

Meine Frage ist: Warum um alles in der Welt enthält es diesen letzten Eintrag in der Ausnahmetabelle?!

So wie ich es verstehe, heißt es im Grunde “wenn die astore_2 eine Ausnahme auslöst, abfangen und dieselbe Anweisung wiederholen“.

Ein solcher Eintrag wird auch mit leeren Try / Catch / Final-Klauseln wie z

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

Einige Beobachtungen

• Der Eclipse-Compiler erzeugt keinen solchen Ausnahmetabelleneintrag
• Die JVM-Spezifikation dokumentiert keine Laufzeitausnahmen für das astore Anweisung.
• Ich weiß, dass es legal ist, die JVM zu werfen VirtualMachineError für jede Anweisung. Ich denke, der eigenartige Eintrag verhindert, dass sich solche Fehler aus dieser Anweisung ausbreiten.

Dafür gibt es nur zwei mögliche Erklärungen: Der Compiler enthält einen Fehler oder er setzt aus obskuren Gründen eine Art Wasserzeichen.

Dieser Eintrag ist sicherlich falsch, da jede Ausnahme, die von einem finally-Block selbst ausgelöst wird, den Ausführungsfluss an den äußeren Ausnahmehandler oder den finally-Block senden muss, aber niemals den gleichen finally-Block “erneut ausführen” muss.

Ein guter Beweis dafür, dass es sich um einen Fehler/ein Wasserzeichen handelt, ist auch die Tatsache, dass Eclipse (und vielleicht andere Java-Compiler) keinen solchen Eintrag generieren, und trotzdem funktionieren von Eclipse generierte Klassen auf Suns JVM einwandfrei.

Dieser Beitrag ist jedoch interessant, da die Klassendatei anscheinend gültig und verifiziert ist. Wenn ich ein JVM-Implementierer wäre, würde ich diesen Eintrag ignorieren und einen Fehler für Sun/Oracle füllen!

Wenn ich mir den Quellcode von OpenJDK 7 ansehe, würde ich es wagen, den Grund dafür zu erraten 28 29 28 any Ausnahmetabelleneintrag liegt daran, dass der Code, der die verarbeitet astore Bytecode (vgl Code ab Zeile 1871) kann ein werfen java.lang.LinkageError Ausnahme, wenn der entnommene Wert aus dem Operandenstapel nicht a ist returnAddress oder reference type (siehe die Java Virtual Machine Specification für ein Laden) und sie möchten, dass diese Fehlerbedingung im Stack-Trace angezeigt wird.

Für den Fall, dass der Operandenstapel einen fehlerhaften Operandentyp enthält, löscht die JVM den Operandenstapel (um diesen fehlerhaften Operanden loszuwerden), fügen Sie a LinkageError
auf dem Operandenstapel und führen Sie die aus astore Bytecode erneut, diesmal erfolgreich ausgeführt astore Bytecode mit einer bereitgestellten JVM LinkageError
Objektbezug. Siehe die werfen Dokumentation für weitere Informationen.

Ich würde stark die Ursache für das Werfen a vermuten LinkageError während
astore Die Verarbeitung erfolgt aufgrund der Komplexitäten JSR/RET-Subroutinen Einführung in die Bytecode-Überprüfung (OpenJDK-Änderungen
6878713, 6932496 und 7020373 sind neuere Beweise dafür JSRdie anhaltende Komplexität von ; Ich bin sicher, dass Sun/Oracle andere Closed-Source-Tests hat, die wir in OpenJDK nicht sehen). Das OpenJDK 7020373 Nutzungen ändern LinkageError um Testergebnisse zu validieren/ungültig zu machen.

Mein Verständnis ist, dass der zweite Eintrag in der Ausnahmetabelle die implizite Catch-Everything-Klausel ist, die vom Compiler hinzugefügt wurde, um alle Ausnahmen/Fehler abzudecken, die im Hauptteil oder in den Catch-Handlern ausgelöst werden, und der dritte Eintrag der Wächter für diesen impliziten Catch ist, um den Fluss zu erzwingen durch die endlich Hinrichtung.