Die Rückgabe von null als int ist mit dem ternären Operator zulässig, jedoch nicht mit der if-Anweisung

Schauen wir uns den einfachen Java-Code im folgenden Snippet an:

public class Main {

    private int temp() {
        return true ? null : 0;
        // No compiler error - the compiler allows a return value of null
        // in a method signature that returns an int.
    }

    private int same() {
        if (true) {
            return null;
            // The same is not possible with if,
            // and causes a compile-time error - incompatible types.
        } else {
            return 0;
        }
    }

    public static void main(String[] args) {
        Main m = new Main();
        System.out.println(m.temp());
        System.out.println(m.same());
    }
}

In diesem einfachsten Java-Code gibt die temp()Methode keinen Compilerfehler aus, obwohl der Rückgabetyp der Funktion lautet int, und wir versuchen, den Wert null(über die Anweisung return true ? null : 0;) zurückzugeben. Beim Kompilieren verursacht dies offensichtlich die Laufzeitausnahme NullPointerException.

Allerdings scheint es , dass die gleiche Sache falsch ist , wenn wir den ternären Operator mit einer darstellen ifAussage (wie im same()Verfahren), das tut einen Fehler bei der Kompilierung Ausgabe! Warum?

Der Compiler interpretiert nullals Nullreferenz auf a Integer, wendet die Autoboxing- / Unboxing-Regeln für den bedingten Operator an (wie in der Java-Sprachspezifikation, 15.25 beschrieben ) und fährt glücklich fort. Dadurch wird NullPointerExceptionzur Laufzeit eine generiert , die Sie durch Ausprobieren bestätigen können.

Ich denke, der Java-Compiler interpretiert true ? null : 0als IntegerAusdruck, der implizit konvertiert werden kann intund möglicherweise gibt NullPointerException.

Für den zweiten Fall ist der Ausdruck nullvom speziellen Nulltyp ( siehe) , sodass der Code return nullden Typ nicht übereinstimmt.

Eigentlich ist alles in der Java-Sprachspezifikation erklärt .

Der Typ eines bedingten Ausdrucks wird wie folgt bestimmt:

• Wenn der zweite und der dritte Operand denselben Typ haben (der der Nulltyp sein kann), ist dies der Typ des bedingten Ausdrucks.

Daher (true ? null : 0)erhält die "Null" in Ihrem einen int-Typ und wird dann automatisch in eine Ganzzahl geschrieben.

Versuchen Sie etwas Ähnliches, um dies zu überprüfen, (true ? null : null)und Sie erhalten den Compilerfehler.

Im Fall der ifAnweisung wird die nullReferenz nicht als IntegerReferenz behandelt, da sie nicht an einem Ausdruck teilnimmt , der die Interpretation als solche erzwingt. Daher kann der Fehler leicht zur Compile-Zeit gefangen werden , weil es klarer ist ein Typ Fehler.

Was den bedingten Operator betrifft, so ? :beantwortet die Java-Sprachspezifikation §15.25 „Bedingter Operator “ dies in den Regeln für die Anwendung der Typkonvertierung:

• Wenn der zweite und der dritte Operand denselben Typ haben (der der Nulltyp sein kann), ist dies der Typ des bedingten Ausdrucks.
  
  Gilt nicht, weil nullnicht int.

---

• Wenn einer der zweiten und dritten Operanden vom Typ Boolean und der Typ des anderen vom Typ Boolean ist, ist der Typ des bedingten Ausdrucks boolean.
  
  Gilt nicht , weil weder , nullnoch intist booleanoder Boolean.

---

• Wenn einer der zweiten und dritten Operanden vom Typ Null ist und der Typ des anderen ein Referenztyp ist, ist der Typ des bedingten Ausdrucks dieser Referenztyp.
  
  Gilt nicht, da nulles vom Nulltyp ist, aber intkein Referenztyp.

---

• Andernfalls gibt es mehrere Fälle, wenn der zweite und dritte Operand Typen haben, die in numerische Typen konvertierbar sind (§5.1.8): […]
  
  Gilt: nullwird als in einen numerischen Typ konvertierbar behandelt und in §5.1 definiert. 8 "Unboxing Conversion", um a zu werfen NullPointerException.

Das erste, was zu beachten ist, ist, dass ternäre Java-Operatoren einen "Typ" haben und dass dies vom Compiler bestimmt und berücksichtigt wird, unabhängig davon, welche tatsächlichen / realen Typen der zweite oder dritte Parameter sind. Abhängig von mehreren Faktoren wird der ternäre Operatortyp auf unterschiedliche Weise bestimmt, wie in der Java-Sprachspezifikation 15.26 dargestellt

In der obigen Frage sollten wir den letzten Fall betrachten:

Ansonsten sind der zweite und der dritte Operand vom Typ S1 bzw. S2 . Sei T1 der Typ, der sich aus der Anwendung der Boxkonvertierung auf S1 ergibt , und sei T2 der Typ, der sich aus der Anwendung der Boxkonvertierung auf S2 ergibt . Der Typ des bedingten Ausdrucks ergibt sich aus der Anwendung der Capture-Konvertierung (§5.1.10) auf lub (T1, T2) (§15.12.2.7).

Dies ist bei weitem der komplexeste Fall, wenn Sie sich die Anwendung der Capture-Konvertierung (§5.1.10) und vor allem lub (T1, T2) ansehen .

Im Klartext und nach einer extremen Vereinfachung können wir den Prozess als Berechnung der "Least Common Superclass" (ja, denken Sie an das LCM) des zweiten und dritten Parameters beschreiben. Dies gibt uns den ternären Operator "Typ". Was ich gerade gesagt habe, ist eine extreme Vereinfachung (betrachten Sie Klassen, die mehrere gemeinsame Schnittstellen implementieren).

Wenn Sie beispielsweise Folgendes versuchen:

long millis = System.currentTimeMillis();
return(true ? new java.sql.Timestamp(millis) : new java.sql.Time(millis));

Sie werden feststellen, dass der resultierende Typ des bedingten Ausdrucks java.util.Datedie "Least Common Superclass" für das Timestamp/ Timepair ist.

Da nullfür alles eine Autobox erstellt werden kann, ist die "Least Common Superclass" die IntegerKlasse und dies ist der Rückgabetyp des obigen bedingten Ausdrucks (ternärer Operator). Der Rückgabewert ist dann ein Nullzeiger vom Typ, Integerund dieser wird vom ternären Operator zurückgegeben.

Zur Laufzeit, wenn die Java Virtual Machine entpackt, wird das Integera NullPointerExceptionausgelöst. Dies geschieht, weil die JVM versucht, die Funktion aufzurufen null.intValue(), nullwas das Ergebnis einer Autobox ist.

Meiner Meinung nach (und da meine Meinung nicht in der Java-Sprachspezifikation enthalten ist, werden viele Leute es sowieso falsch finden) leistet der Compiler schlechte Arbeit bei der Bewertung des Ausdrucks in Ihrer Frage. Vorausgesetzt, Sie haben geschrieben, sollte true ? param1 : param2der Compiler sofort bestimmen, dass der erste Parameter - null- zurückgegeben wird, und er sollte einen Compilerfehler erzeugen. Dies ist etwas ähnlich wie beim Schreiben while(true){} etc...und der Compiler beschwert sich über den Code unter der Schleife und kennzeichnet ihn mit Unreachable Statements.

Dein zweiter Fall ist ziemlich einfach und diese Antwort ist schon zu lang ...;)

KORREKTUR:

Nach einer weiteren Analyse glaube ich, dass ich zu Unrecht gesagt habe, dass ein nullWert für alles eingerahmt / autoboxed werden kann. Wenn wir über die Klasse Integer sprechen, besteht explizites Boxen darin, den new Integer(...)Konstruktor oder vielleicht das aufzurufen Integer.valueOf(int i);(ich habe diese Version irgendwo gefunden). Ersteres würde ein werfen NumberFormatException(und das passiert nicht), während das zweite einfach keinen Sinn ergeben würde, da ein intnicht sein kann null...

Tatsächlich kann der Ausdruck im ersten Fall ausgewertet werden, da der Compiler weiß, dass er als ausgewertet werden muss. IntegerIm zweiten Fall kann der Typ des Rückgabewerts ( null) jedoch nicht bestimmt werden, sodass er nicht kompiliert werden kann. Wenn Sie es Integerumwandeln, wird der Code kompiliert.

private int temp() {

    if (true) {
        Integer x = null;
        return x;// since that is fine because of unboxing then the returned value could be null
        //in other words I can say x could be null or new Integer(intValue) or a intValue
    }

    return (true ? null : 0);  //this will be prefectly legal null would be refrence to Integer. The concept is one the returned
    //value can be Integer 
    // then null is accepted to be a variable (-refrence variable-) of Integer
}

Wie wäre es damit:

public class ConditionalExpressionType {

    public static void main(String[] args) {

        String s = "";
        s += (true ? 1 : "") instanceof Integer;
        System.out.println(s);

        String t = "";
        t += (!true ? 1 : "") instanceof String;
        System.out.println(t);

    }

}

Die Ausgabe ist wahr, wahr.

Die Eclipse-Farbe codiert die 1 im bedingten Ausdruck als Autobox.

Ich vermute, der Compiler sieht den Rückgabetyp des Ausdrucks als Objekt.