Wyjątek NullPointerException dzięki automatycznemu bokserskiemu działaniu trójargumentowego operatora Java
Potknąłem się o naprawdę dziwnyNullPointerException
inny dzień spowodowany nieoczekiwanym rzutem w operatorze trójskładnikowym. Biorąc pod uwagę tę (bezużyteczną przykładową) funkcję:
Integer getNumber() {
return null;
}
Po kompilacji spodziewałem się, że następujące dwa segmenty kodu będą identyczne:
Integer number;
if (condition) {
number = getNumber();
} else {
number = 0;
}
vs.
Integer number = (condition) ? getNumber() : 0;
.
Okazuje się, jeślicondition
jesttrue
, theif
-statement działa dobrze, podczas gdy trójskładnikowy opracja w drugim segmencie kodu rzuca aNullPointerException
. Wygląda na to, że operacja trójskładnikowa postanowiła wpisać oba wyboryint
przed automatycznym wstawieniem wyniku z powrotem doInteger
!?! W rzeczywistości, jeśli wyraźnie rzucę0
doInteger
, wyjątek zniknie. Innymi słowy:
Integer number = (condition) ? getNumber() : 0;
nie jest tym samym co:
Integer number = (condition) ? getNumber() : (Integer) 0;
.
Wydaje się więc, że istnieje różnica między kodem bajtowym między operatorem trójskładnikowym a odpowiednikiemif-else
-statement (coś, czego się nie spodziewałem). Co rodzi trzy pytania: Dlaczego istnieje różnica? Czy jest to błąd w implementacji trójskładnikowej, czy istnieje powód rzucania typu? Biorąc pod uwagę różnicę, czy operacja trójskładnikowa jest bardziej lub mniej skuteczna niż odpowiednikif
-statement (wiem, różnica nie może być ogromna, ale wciąż)?