2012-11-08 15 views
12

immer, dass primitive Typen in Java nicht null sein kann, da es sich um eine Kompilierung Fehler ist, wenn ich so etwas wie dies zu tun versuchen:warum ich einstellen kann dachte ich Urtyp zu null in ternären Operationen

int test = null; 

jedoch in einem ternären Betrieb, so scheint es erlaubt zu sein:

int test = something != 0 ? 5 : null; 

Ist das nicht ein ternärer Betrieb nur kurz für (in diesem Fall):

int test; 
if (something != 0){ 
    test = 5; 
} else { 
    test = null 
} 

was natürlich nicht erlaubt sein sollte. Wenn diese Bedingung fehlschlägt, wird automatisch ein NullPointerException wegen Autoboxing geworfen. Warum also ruft der Java-Compiler keinen solchen Unsinn?

+1

Übrigens, Sie reden von * primitiven * Typen. Rohtypen sind etwas völlig anderes. http://docs.oracle.com/javase/tutorial/java/generics/rawTypes.html – Natix

+0

Ihr Recht! Ich verwirrte sie einfach und änderte sie entsprechend. –

+0

mögliches Duplikat von [Tricky ternärer Operator in Java - Autoboxing] (http://stackoverflow.com/questions/8098953/tricky-ternary-operator-in-java-autoboxing) –

Antwort

12

Was passiert ist, dass der Java-Compiler zuerst versucht, die Typen der Ausdrücke auf beiden Seiten der : gleich zu machen. In diesem Fall autoboxiert es die 5 zu einer Integer; Beachten Sie, dass null ein gültiger Wert für Integer ist. Das Ergebnis des gesamten ternären Ausdrucks ist Integer. Sie ordnen das einem int zu, also wird das Integer dann automatisch eingestellt.

Im Wesentlichen gilt der Compiler Autoboxing und -unboxing, so dass die Zeile wie folgt aussehen wird:

int test = (something != 0 ? Integer.valueOf(5) : null).intValue(); 

Tat autounboxing null zu einem NullPointerException führt.

Warum also der Java-Compiler nicht Quatsch wie diesen?

Weil die Designer der Java-Sprache, die Sprache so definiert, dass es wie das funktioniert und entscheiden nicht, dass dies als Fehler behandelt werden muss ...

Section 15.25 der Java Die Sprachspezifikation erläutert, wie der Typ des gesamten Ausdrucks bestimmt wird.

+0

@nhahtdh Warum denkst du das? – Jesper

+0

Sorry, macht nichts. Du hast recht. Es ist Verwirrung meinerseits beim Lesen des disassemblierten Codes. – nhahtdh