Compiler-Fehler final Variable in try-catch Wert zuweisen

[xehpuk]

Moin!

Ich wage mich mal wieder ins Anfängerforum.

Folgender Code:

public class MayHaveBeenAssigned {
	private final int i;
	
	{
		try {
			i = Integer.parseInt("0");
		} catch (NumberFormatException e) {
			i = 0;
		}
	}
}

Compilerfehler in Zeile 8: "The final field i may already have been assigned"

In welchem Fall denn? Dasselbe übrigens auch bei checked exceptions.

Und wie soll man es denn sonst machen?

 

[maki]

Ohne final.

Der Compiler ist da ein bisschen doof.

 

[faetzminator]

Oder lass es bei [c]final[/c] und mach eine eigene Methode draus...

 

[xehpuk]

Ohne final wärs ja ein blöder Würgaround.

Kann man das als Bug ansehen? Würde das dann gern Oracle zukommen lassen.

Den Vorschlag mit der eigenen Methode verstehe ich nicht. Wie meinst du das?

 

[maki]

Kein Bug, kannst aber mal an Oracle schreiben *g*

faetzminators Vorschlag (sehr gut übrigens) läuft darauf hinaus, den try/catch Block in eine eigene Methode auszulagern, dann klappts auch mit dem final.

 

[Marco13]

Naja, einen Bug würde ich das auch nicht nennen, ... aber "intuitiv falsch" schon. Hab sogar mal kurz getestet: Es hätte mich nicht gewundert, wenn er

            int j=0;
            j = Integer.parseInt("0");
            i = j;

erlaubt hätte, aber auch das akzeptiert er nicht. Es gilt wohl der Block, in dem etwas passiert, und geht NICHT um die Frage, WO genau die Exception ausgelöst wird oder werden könnte. Bei

            int j=0;
            i = j;
            j = Integer.parseInt("0");

wäre es ja auch klar...

Aber was will man schon von einem Computer erwarten, der sich über

int crap() {
    return 123;
    return 234; // ~Error: Statement not reached....
}

beschwert, aber

int crap() {
    if (true) return 123;
    return 234;
}

durchgehen läßt

 

[nillehammer]

Den Vorschlag mit der eigenen Methode verstehe ich nicht. Wie meinst du das?

public class MayHaveBeenAssigned {
    // Wird im Konstruktor initialisiert.
    private final int i;
    // Direkt initialisieren geht auch.
    private final int j = parseWithoutException("1");

     public MayHaveBeenAssigned(final String intStr) {
         this.i = parseWithoutException(intStr);
     }
    
    private static final int parseWithoutException(final String numberStr ) {
        try {
            return Integer.parseInt(numberStr);
        }
        catch (NumberFormatException e) {
           // evtl. loggen
           return 0;
        }
    }
}

 

[xehpuk]

Ah, danke. Jetzt leuchtets mir ein. Finde den Compiler weiterhin doof, aber das Problem an sich ist gelöst. Erledigt!

 

[musiKk]

Es hätte mich nicht gewundert, wenn er

            int j=0;
            j = Integer.parseInt("0");
            i = j;

erlaubt hätte, aber auch das akzeptiert er nicht.

Huh? Das geht doch sowohl in Eclipse als auch mit dem [c]javac[/c]?

Falls es wen interessiert: Ich glaube, die JVM macht es unmöglich, diesen Fall wie hier gewünscht zu übersetzen. Exception Handling ist dafür zu transparent. Ich habe mal eine Version dekompiliert, die eine Exception wirft, statt versucht, einen Default-Wert zuzuweisen (das geht ja bekanntlich nicht).

 0 aload_0
 1 invokespecial #1 <java/lang/Object.<init>>
 4 aload_0
 5 ldc #2 <0>
 7 invokestatic #3 <java/lang/Integer.parseInt>
10 putfield #4 <Test.i>
13 goto 26 (+13)
16 astore_1
17 new #6 <java/lang/RuntimeException>
20 dup
21 aload_1
22 invokespecial #7 <java/lang/RuntimeException.<init>>
25 athrow
26 return

Dazu gibt es einen Exception Table mit einem Eintrag von 5 bis 13 und dem Handler ab 16.

Das heißt egal wo in 5 bis 13 eine NFE auftritt, der Exception Handler 16 wird angesprungen. Es kann also nicht unterschieden werden, ob die Instruktion 10 schon durchgeführt wurde oder nicht. Damit ist es aus JVM-Sicht möglich, dass [c]i[/c] zwei mal einen Wert zugewiesen bekommt; einmal in 10 und einmal um 17 herum wo jetzt die Exception geworfen wird.

Das einzige, was mir nicht hundertprozentig klar ist, ist, warum der Eintrag im Exception Table überhaupt bis 13 gehen muss und nicht einfach nur 7 abdeckt. Damit sollte nämlich alles klar sein. Allerdings erhalte ich obiges Resultat sowohl in Eclipse als auch mit dem [c]javac[/c] und es entspricht auch den Beispielen in der JVMS. Von daher gehe ich davon aus, dass es dafür einen Grund gibt.