Повернення null у вигляді int дозволено з потрійним оператором, але не якщо оператор

Давайте розглянемо простий код Java в наступному фрагменті:

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

У цьому найпростішому коді Java temp()метод не видає помилки компілятора, хоча тип повернення функції є int, і ми намагаємось повернути значення null(через оператор return true ? null : 0;). Коли компілюється, це очевидно спричиняє виняток із часу запуску NullPointerException.

Тим НЕ менше, виявляється , що те ж саме , це не так , якщо ми представляємо трикомпонентний оператор з ifтвердженням (як в same()методі), який робить видає помилку під час компіляції! Чому?

Компілятор інтерпретує nullяк нульове посилання на an Integer, застосовує правила автобоксингу / розпакування для умовного оператора (як описано в специфікації мови Java, 15.25 ) і радісно рухається далі. Це створить час NullPointerExceptionвиконання, що ви можете підтвердити, спробувавши його.

Я думаю, компілятор Java трактує true ? null : 0як Integerвираз, який можна неявно перетворити int, можливо, даючи NullPointerException.

У другому випадку вираз nullмає спеціальний нульовий тип see , тому код return nullробить тип невідповідним.

Власне, все це пояснено в специфікації мови Java .

Тип умовного виразу визначається наступним чином:

• Якщо другий і третій операнди мають один і той же тип (який може бути нульовим типом), то це тип умовного виразу.

Тому "null" у вашому (true ? null : 0)значенні отримує тип int, а потім автоматично завантажується в Integer.

Спробуйте щось подібне, щоб перевірити це, (true ? null : null)і ви отримаєте помилку компілятора.

У випадку ifтвердження, nullпосилання не трактується як Integerпосилання, оскільки воно не бере участі у виразі, що змушує його інтерпретувати як таке. Тому помилка може бути легко виявлена ​​під час компіляції, оскільки це явніше помилка типу .

Що стосується умовного оператора, специфікація мови Java §15.25 «Умовний оператор ? :» відповідає на це чудово в правилах застосування способу перетворення типів:

• Якщо другий і третій операнди мають один і той же тип (який може бути нульовим типом), то це тип умовного виразу.
  
  Не застосовується, тому що nullні int.

---

• Якщо один з другого і третього операндів має тип булевого типу, а другий тип булевого типу, то тип умовного виразу булевий.
  
  Не застосовується, тому що ні, nullні int, booleanні Boolean.

---

• Якщо один з другого та третього операндів має нульовий тип, а тип другого є еталонним типом, то тип умовного виразу є таким еталонним типом.
  
  Не застосовується, оскільки nullмає нульовий тип, але intне є еталонним.

---

• В іншому випадку, якщо другий та третій операнди мають типи, які перетворюються (§5.1.8) в числові типи, то є кілька випадків: […]
  
  Застосовується: nullтрактується як конвертований у числовий тип і визначається у §5.1. 8 "Конверсія для розпакування", щоб кинути NullPointerException.

Перше, що слід пам’ятати, це те, що потрійні оператори Java мають «тип», і що саме це визначатиме компілятор і враховує, незалежно від того, які фактичні / реальні типи другого або третього параметра. Залежно від декількох факторів тип потрійного оператора визначається різними способами, як показано в специфікації мови Java 15.26

У вищезазначеному питанні ми повинні розглянути останній випадок:

В іншому випадку другий і третій операнди мають типи S1 і S2 відповідно. Нехай T1 - тип, який є результатом застосування перетворення боксу до S1 , а T2 - тип, який є результатом застосування перетворення боксу до S2 . Тип умовного виразу є результатом застосування перетворення захоплення (§5.1.10) до лубу (T1, T2) (§15.12.2.7).

Це, безумовно, найскладніший випадок, коли ви подивитесь на застосування конверсії захоплення (§5.1.10), а найбільше - на луб (T1, T2) .

Простий англійською мовою і після надзвичайного спрощення ми можемо описати процес як обчислення "Найменшого загального суперкласу" (так, подумайте про LCM) другого та третього параметрів. Це дасть нам потрійний оператор "типу". Знову ж таки, те, що я щойно сказав, - це надзвичайне спрощення (розглянемо класи, які реалізують кілька загальних інтерфейсів).

Наприклад, якщо ви спробуєте наступне:

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

Ви помітите, що отриманий тип умовного виразу є java.util.Dateтим, що це "Найменший загальний суперклас" для Timestamp/ Timeпари.

Оскільки nullйого можна автокорегувати будь-чим, то "Найменший загальний надклас" - це Integerклас, і це буде тип повернення умовного виразу (потрійний оператор) вище. Значення, що повертається, буде нульовим покажчиком типу, Integerі саме це повернеться термінальним оператором.

Під час виконання, коли віртуальна машина Java розблоковує , викидається Integera NullPointerException. Це відбувається тому, що JVM намагається викликати функцію null.intValue(), де nullє результатом автобоксингу.

На мою думку (а оскільки моя думка відсутня в специфікації мови Java, багато людей вважають це неправильним), компілятор робить погану роботу в оцінці виразу у вашому запитанні. Враховуючи, що ви написали, true ? param1 : param2компілятор повинен відразу визначити, що перший параметр - null- буде повернутий, і він повинен створити помилку компілятора. Це дещо схоже на те, коли ви пишете, while(true){} etc...і компілятор скаржиться на код під циклом і позначає його Unreachable Statements.

Ваш другий випадок досить простий, і ця відповідь вже занадто довга ...;)

КОРЕКЦІЯ:

Після іншого аналізу я вважаю, що я помилявся, сказавши, що nullзначення може бути встановлено в коробці / автобоксировано до будь-чого. Якщо говорити про клас Integer, то явний бокс полягає у виклику new Integer(...)конструктора чи, можливо, Integer.valueOf(int i);(я знайшов цю версію десь). Перший кине NumberFormatException(а цього не відбувається), а другий просто не має сенсу, оскільки не intможе бути null...

Насправді, у першому випадку вираз можна оцінити, оскільки компілятор знає, що він повинен бути оцінений як an Integer, однак у другому випадку тип повернутого значення ( null) не може бути визначений, тому його неможливо скласти. Якщо ви кинете його Integer, код скомпілюватиметься.

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
}

Як щодо цього:

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

    }

}

Вихід вірний, правдивий.

Колір затемнення кодує 1 у умовному виразі як автозахисне зображення.

Я думаю, що компілятор бачить тип повернення виразу як Object.