Üçlü işleçle izin verilen bir int olarak null döndürme ancak if ifadesi

Aşağıdaki kod parçasındaki basit Java koduna bakalım:

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());
    }
}

Bu en basit Java kodunda, temp()işlevin dönüş türü olmasına rağmen yöntem , derleyici hatası vermez intve değeri null(ifade aracılığıyla return true ? null : 0;) döndürmeye çalışıyoruz . Derlendiğinde, bu açıkça çalışma zamanı istisnasına neden olur NullPointerException.

Ancak, üçlü işleci derleme zamanı hatası veren bir ifdeyimle ( same()yöntemde olduğu gibi ) temsil edersek aynı şey yanlış görünüyor ! Neden?

Derleyici , a'ya nullboş bir başvuru olarak yorumlar Integer, koşullu işleç için otomatik kutulama / kutudan çıkarma kurallarını uygular ( Java Dil Belirtimi, 15.25'te açıklandığı gibi ) ve mutlu bir şekilde devam eder. Bu, bir NullPointerExceptionçalışma zamanında oluşturur ve bunu deneyerek onaylayabilirsiniz.

Java derleyicisi , örtük olarak dönüştürülebilen ve muhtemelen verilebilen true ? null : 0bir Integerifade olarak yorumlar .intNullPointerException

İkinci durumda, ifade nullözel taşımaktadır null türü See kodu yüzden, return nulltip uyuşmazlığı yapar.

Aslında, bunların hepsi Java Dil Spesifikasyonunda açıklanmıştır .

Koşullu ifadenin türü aşağıdaki gibi belirlenir:

• İkinci ve üçüncü işlenenler aynı türe sahipse (boş tip olabilir), bu koşullu ifadenin türüdür.

Bu nedenle, "null" (true ? null : 0)bir int türü alır ve sonra tamsayı otomatik kutuya alınır.

Bunu doğrulamak için böyle bir şey deneyin (true ? null : null)ve derleyici hatası alırsınız.

Durumunda ifaçıklamaya nullreferans bir şekilde tedavi edilmezse Integerbir katılan değildir, çünkü referans ekspresyonu bu gibi yorumlanmamalıdır zorlar. Bu nedenle hata derleme zamanında kolayca yakalanabilir çünkü daha açık bir tür hatasıdır.

Koşullu operatöre gelince, Java Dil Spesifikasyonu §15.25 “Koşullu Operatör ? :”, tip dönüşümünün nasıl uygulandığı kurallarında bunu güzel bir şekilde cevaplar:

• İkinci ve üçüncü işlenenler aynı türe sahipse (boş tip olabilir), bu koşullu ifadenin türüdür.
  
  Uygulanmaz çünkü nulldeğildir int.

---

• İkinci ve üçüncü işlenenlerden biri boolean türünde, diğeri ise Boolean türündeyse, koşullu ifadenin türü boolean olur.
  
  Ne çünkü geçerli değildir nullne de intbir booleanveya Boolean.

---

• İkinci ve üçüncü işlenenlerden biri null tipindeyse ve diğerinin tipi bir referans tipiyse, koşullu ifadenin tipi o referans tipidir.
  
  Çünkü geçerli değildir nullboş tiptedir, ancak intbir başvuru türü değil.

---

• Aksi takdirde, ikinci ve üçüncü işlenenler sayısal türlere dönüştürülebilir (§5.1.8) türlere sahipse, birkaç durum vardır: […]
  
  Uygulanır:null sayısal bir türe dönüştürülebilir olarak kabul edilir ve §5.1'de tanımlanır. 8 “Kutusundan Kutunun Açılması” a NullPointerException.

Akılda tutulması gereken ilk şey, Java üçlü operatörlerinin bir "tip" e sahip olması ve ikinci veya üçüncü parametrenin gerçek / gerçek türleri ne olursa olsun, derleyicinin belirleyeceği ve dikkate alacağı şeydir. Çeşitli faktörlere bağlı olarak, üçlü operatör tipi, çizimde gösterildiği gibi farklı şekillerde belirlenir. Java Dil Spesifikasyonu 15.26'da

Yukarıdaki soruda son durumu dikkate almalıyız:

Aksi takdirde, ikinci ve üçüncü işlenenler sırasıyla S1 ve S2 tipindedir. T1 , S1'e boks dönüşümü uygulanmasından kaynaklanan tür olsun ve T2 , S2'ye boks dönüşümü uygulanmasından kaynaklanan tür olsun . Koşullu ifadenin türü, lub'a (T1, T2) (§15.12.2.7) yakalama dönüşümü (§5.1.10) uygulanmasının sonucudur .

Bu, yakalama dönüşümünü (§5.1.10) ve en önemlisi lub'ta (T1, T2) bir kez baktığınızda en karmaşık durumdur .

Sade İngilizce'de ve aşırı basitleştirmeden sonra, süreci ikinci ve üçüncü parametrelerin "En Küçük Ortak Süper Sınıfı" (evet, LCM'yi düşünün) hesaplamak olarak tanımlayabiliriz. Bu bize üçlü operatör "tip" verecektir. Yine, az önce söylediğim şey aşırı basitleştirmedir (birden fazla ortak arabirimi uygulayan sınıfları düşünün).

Örneğin, aşağıdakileri denerseniz:

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

Ortaya çıkan koşullu ifadenin java.util.Datetürünün, Timestamp/ Timeçifti için "En Küçük Ortak Üst Sınıf" olduğu için fark edeceksiniz .

Yana nullhiçbir şeye autoboxed edilebilir "Asgari Ortak Üst sınıf" dir Integersınıf ve bu yukarıdaki koşullu ifadenin (üçlü operatör) dönüş tipi olacaktır. Dönüş değeri daha sonra tipte bir boş gösterici olacaktırInteger olacaktır ve üçlü operatör tarafından döndürülecek olan budur.

Çalışma zamanında, Java Sanal Makinesi kutusundan çıktığında Integera NullPointerExceptionatılır. JVM girişimleri işlevini çağırmak için Bunun nedeni null.intValue(), nullAutoboxing sonucudur.

Benim düşünceme göre (ve benim fikrim Java Dil Spesifikasyonunda olmadığı için birçok kişi yine de yanlış bulacak) derleyici sorunuzdaki ifadeyi değerlendirmede kötü bir iş çıkarıyor. true ? param1 : param2Derleyici yazdığınız göz önüne alındığında, derhal ilk parametrenin - null- döndürüleceğini ve bir derleyici hatası oluşturması gerektiğini belirlemelidir . Bu, yazarken while(true){} etc...ve derleyici döngünün altındaki koddan şikayet edip işaretlediğinde biraz benzer Unreachable Statements.

İkinci davanız oldukça basit ve bu cevap zaten çok uzun ...;)

DÜZELTME:

Başka bir analizden sonra, bir nulldeğerin herhangi bir şeye kutulanabileceğini / otomatik olarak kutulanabileceğini söylemenin yanlış olduğuna inanıyorum . Sınıf Integer hakkında konuşmak, açık boks new Integer(...)yapıcı ya da belki Integer.valueOf(int i);(Bu sürümü bir yerde buldum) çağırmak oluşur . Birincisi alamazdı NumberFormatException(ve bu gerçekleşmez), ikincisi mantıklı olmaz çünkü bir intolamaz null...

Aslında, birinci durumda ifade değerlendirilebilir, çünkü derleyici bunun bir olarak değerlendirilmesi gerektiğini bilir, Integerancak ikinci durumda dönüş değerinin ( null) tipi belirlenemez, bu yüzden derlenemez. Eğer yayın yaparsanız Integer, kod derlenir.

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
}

Buna ne dersin:

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);

    }

}

Çıktı doğrudur, doğrudur.

Tutulma rengi, koşullu ifadedeki 1 değerini otomatik kutulu olarak kodlar.

Tahminimce derleyici ifadenin dönüş türünü Object olarak görüyor.