NullPointerException durch Auto-Boxing-Verhalten des Java-Ternary-Operators
Ich stolperte über eine wirklich seltsameNullPointerException
neulich verursacht durch eine unerwartete Typumwandlung im ternären Operator. In Anbetracht dieser (unnütz beispielhaften) Funktion:
Integer getNumber() {
return null;
}
Ich habe erwartet, dass die folgenden beiden Codesegmente nach der Kompilierung exakt identisch sind:
Integer number;
if (condition) {
number = getNumber();
} else {
number = 0;
}
gegen
Integer number = (condition) ? getNumber() : 0;
.
Es stellt sich heraus, wenncondition
isttrue
, dasif
-Anweisung funktioniert einwandfrei, während die ternäre Operation im zweiten Codesegment a auslöstNullPointerException
. Es scheint, als ob die ternäre Operation beschlossen hat, beide Optionen zu tippenint
bevor Sie das Ergebnis automatisch wieder in einInteger
!?! In der Tat, wenn ich das explizit besetze0
zuInteger
, die ausnahme geht weg. Mit anderen Worten:
Integer number = (condition) ? getNumber() : 0;
ist nicht dasselbe wie:
Integer number = (condition) ? getNumber() : (Integer) 0;
.
Es scheint also einen Unterschied im Bytecode zwischen dem ternären Operator und einem Äquivalent zu gebenif-else
-Statement (etwas, mit dem ich nicht gerechnet habe). Was drei Fragen aufwirft: Warum gibt es einen Unterschied? Ist dies ein Fehler in der ternären Implementierung oder gibt es einen Grund für die Typumwandlung? Wenn es einen Unterschied gibt, ist die ternäre Operation mehr oder weniger performant als eine äquivalenteif
-Statement (Ich weiß, der Unterschied kann nicht groß sein, aber immer noch)?