Mengembalikan nol sebagai int diizinkan dengan operator ternary tetapi tidak jika pernyataan

Mari kita lihat kode Java sederhana dalam cuplikan berikut:

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

Dalam kode Java yang paling sederhana ini, temp()metode ini tidak mengeluarkan kesalahan kompiler meskipun jenis fungsi yang dikembalikan adalah int, dan kami mencoba mengembalikan nilainya null(melalui pernyataan return true ? null : 0;). Saat dikompilasi, ini jelas menyebabkan pengecualian waktu berjalan NullPointerException.

Namun, tampaknya hal yang sama salah jika kita mewakili operator ternary dengan ifpernyataan (seperti dalam same()metode), yang memang mengeluarkan kesalahan waktu kompilasi! Mengapa?

Compiler mengartikan nullsebagai referensi nol ke Integer, menerapkan aturan autoboxing / unboxing untuk operator bersyarat (seperti yang dijelaskan dalam Spesifikasi Bahasa Jawa, 15.25 ), dan bergerak dengan senang hati. Ini akan menghasilkan NullPointerExceptionwaktu berjalan, yang dapat Anda konfirmasikan dengan mencobanya.

Saya pikir, kompiler Java mengartikan true ? null : 0sebagai Integerekspresi, yang dapat secara implisit dikonversi menjadi int, mungkin memberi NullPointerException.

Untuk kasus kedua, ekspresi nulladalah khusus jenis nol lihat , sehingga kode return nullmembuat jenis ketidakcocokan.

Sebenarnya, itu semua dijelaskan dalam Spesifikasi Bahasa Jawa .

Jenis ekspresi kondisional ditentukan sebagai berikut:

• Jika operan kedua dan ketiga memiliki tipe yang sama (yang mungkin merupakan tipe nol), maka itu adalah tipe ekspresi kondisional.

Oleh karena itu "null" di Anda (true ? null : 0)mendapat tipe int dan kemudian diautobox ke Integer.

Coba sesuatu seperti ini untuk memverifikasi ini (true ? null : null)dan Anda akan mendapatkan kesalahan kompiler.

Dalam kasus ifpernyataan, nullreferensi tidak diperlakukan sebagai Integerreferensi karena tidak berpartisipasi dalam ekspresi yang memaksanya untuk ditafsirkan seperti itu. Oleh karena itu kesalahan dapat dengan mudah ditangkap pada waktu kompilasi karena lebih jelas kesalahan jenis .

Adapun operator kondisional, Spesifikasi Bahasa Jawa §15.25 "Operator Bersyarat ? :" menjawab ini dengan baik dalam aturan untuk bagaimana konversi tipe diterapkan:

• Jika operan kedua dan ketiga memiliki tipe yang sama (yang mungkin merupakan tipe nol), maka itu adalah tipe ekspresi kondisional.
  
  Tidak berlaku karena nulltidak int.

---

• Jika salah satu dari operan kedua dan ketiga adalah tipe boolean dan tipe lainnya adalah tipe Boolean, maka jenis ekspresi kondisional adalah boolean.
  
  Tidak berlaku karena tidak nulljuga intadalah booleanatau Boolean.

---

• Jika salah satu dari operan kedua dan ketiga adalah tipe nol dan tipe yang lain adalah tipe referensi, maka tipe ekspresi kondisional adalah tipe referensi tersebut.
  
  Tidak berlaku karena nulladalah tipe null, tetapi intbukan tipe referensi.

---

• Kalau tidak, jika operan kedua dan ketiga memiliki tipe yang dapat dikonversi (§5.1.8) ke tipe numerik, maka ada beberapa kasus: [...]
  
  Berlaku: nulldiperlakukan sebagai konversi ke tipe numerik, dan didefinisikan dalam §5.1. 8 "Konversi Penghapusan Kotak" untuk melempar a NullPointerException.

Hal pertama yang perlu diingat adalah bahwa operator ternary Java memiliki "tipe", dan bahwa inilah yang akan ditentukan dan dipertimbangkan oleh kompilator apa pun tipe aktual / nyata dari parameter kedua atau ketiga. Tergantung pada beberapa faktor, tipe operator ternary ditentukan dengan cara berbeda seperti yang diilustrasikan dalam Spesifikasi Bahasa Jawa 15.26

Dalam pertanyaan di atas kita harus mempertimbangkan kasus terakhir:

Jika tidak, operan kedua dan ketiga adalah tipe S1 dan S2 masing-masing. Misalkan T1 adalah tipe yang dihasilkan dari penerapan konversi tinju ke S1 , dan biarkan T2 adalah tipe yang dihasilkan dari penerapan konversi tinju ke S2 . Jenis ekspresi kondisional adalah hasil dari penerapan konversi tangkap (§5.1.10) ke lub (T1, T2) (§15.12.2.7).

Sejauh ini, ini adalah kasus yang paling rumit setelah Anda menerapkan konversi tangkapan (§5.1.10) dan yang paling utama di lub (T1, T2) .

Dalam bahasa Inggris biasa dan setelah penyederhanaan ekstrim kita dapat menggambarkan proses sebagai penghitungan "Least Common Superclass" (ya, pikirkan LCM) dari parameter kedua dan ketiga. Ini akan memberi kita "tipe" operator ternary. Sekali lagi, apa yang baru saja saya katakan adalah penyederhanaan ekstrem (pertimbangkan kelas yang mengimplementasikan beberapa antarmuka umum).

Misalnya, jika Anda mencoba yang berikut:

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

Anda akan melihat bahwa jenis ekspresi kondisional yang dihasilkan adalah java.util.Date"Least Common Superclass" untuk Timestamp/ Timepair.

Karena nulldapat diautobox ke apa pun, "Least Common Superclass" adalah Integerkelas dan ini akan menjadi tipe kembalinya ekspresi kondisional (operator ternary) di atas. Nilai kembali kemudian akan menjadi pointer nol dari jenis Integerdan itulah yang akan dikembalikan oleh operator ternary.

Saat runtime, ketika Java Virtual Machine membuka kotak Integera NullPointerExceptiondilemparkan. Ini terjadi karena JVM mencoba untuk memanggil fungsi null.intValue(), di mana nulladalah hasil dari autoboxing.

Menurut pendapat saya (dan karena pendapat saya tidak ada dalam Spesifikasi Bahasa Jawa, banyak orang akan menganggapnya salah) penyusun melakukan pekerjaan yang buruk dalam mengevaluasi ekspresi dalam pertanyaan Anda. Mengingat bahwa Anda menulis true ? param1 : param2kompiler harus segera menentukan bahwa parameter pertama - null- akan dikembalikan dan itu akan menghasilkan kesalahan kompiler. Ini agak mirip dengan ketika Anda menulis while(true){} etc...dan kompiler mengeluh tentang kode di bawah loop dan menandainya Unreachable Statements.

Kasus kedua Anda cukup mudah dan jawaban ini sudah terlalu lama ...;)

KOREKSI:

Setelah analisis lain, saya percaya bahwa saya salah mengatakan bahwa suatu nullnilai dapat dikotak / diautobosisikan ke apa saja. Berbicara tentang Integer kelas, tinju eksplisit terdiri dari memanggil new Integer(...)konstruktor atau mungkin Integer.valueOf(int i);(saya menemukan versi ini di suatu tempat). Yang pertama akan melempar NumberFormatException(dan ini tidak terjadi) sementara yang kedua tidak akan masuk akal karena inttidak bisa null...

Sebenarnya, dalam kasus pertama ekspresi dapat dievaluasi, karena kompiler tahu, bahwa itu harus dievaluasi sebagai Integer, namun dalam kasus kedua jenis nilai pengembalian ( null) tidak dapat ditentukan, sehingga tidak dapat dikompilasi. Jika Anda melemparkannya ke Integer, kode akan dikompilasi.

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
}

Bagaimana dengan ini:

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

    }

}

Outputnya benar, benar.

Kode warna gerhana 1 dalam ekspresi bersyarat sebagai diautobox.

Dugaan saya adalah kompiler melihat tipe pengembalian ekspresi sebagai Object.