Разберите поведение фрагмента: что будет выведено и какое исключение фактически возникнет? пример с кодом

public class Demo {
    public static void main(String[] args) {
        try {
            throw null;
        } catch (NullPointerException e) {
            System.out.println("caught");
        }
    }
}

Краткий ответ

Программа выведет caught. Выражение throw null компилируется, но при выполнении JVM обнаруживает, что передан нулевой ссылочный объект, и выбрасывает NullPointerException.

Исторический контекст

Механизм исключений Java построен вокруг иерархии объектов, корнем которой является Throwable. Оператор throw принимает выражение ссылочного типа, совместимого с Throwable; специального запрета на значение null в синтаксисе языка нет.

Такое поведение согласуется с общей моделью Java: null может иметь любой ссылочный тип, но обращение к отсутствующему объекту выявляется во время выполнения. Поэтому корректность типа проверяется компилятором, а проверка самого значения происходит JVM.

Постановка проблемы

Разработчик может ошибочно считать, что throw null ничего не выбросит или приведёт к исключению с «нулевым» объектом. Это опасно при анализе сгенерированного кода, рефакторинге и диагностике: фактической причиной сбоя становится NullPointerException, хотя в исходнике явно не указано создание этого исключения.

Неверное понимание может привести к неправильному catch, потере причины ошибки или к выводу, что исключение невозможно перехватить из-за отсутствия объекта.

Подробное решение

Для throw компилятор проверяет, что выражение совместимо с Throwable. У литерала null есть специальный тип null, который совместим с любым ссылочным типом, включая Throwable, поэтому строка проходит компиляцию.

Во время выполнения оператор передаёт ссылочное значение механизму выбрасывания исключений. Если ссылка не равна null, JVM выбрасывает указанный объект. Если ссылка равна null, JVM сама создаёт и выбрасывает NullPointerException.

Исключение затем проходит обычный поиск обработчика по стеку вызовов. NullPointerException является наследником RuntimeException, поэтому его можно перехватить данным catch; переменная e будет ссылаться уже на реально созданный объект исключения, а не на null.

Проверяемое это исключение или непроверяемое, для результата несущественно: NullPointerException относится к RuntimeException, поэтому объявление в throws и обязательная обработка не требуются. В прикладном коде throw null не следует использовать намеренно: он скрывает источник ошибки и ухудшает диагностику.

Минимальная демонстрация того же механизма:

static void run() {
    try {
        Throwable failure = null;
        throw failure;
    } catch (NullPointerException e) {
        System.out.println(e.getClass().getSimpleName());
    }
}

Здесь переменная имеет допустимый тип Throwable, но содержит null. В результате будет выведено NullPointerException.

Ситуация из практики

Представим инфраструктурный код, который получает объект исключения из необязательного поля и без проверки передаёт его в throw. В рабочем сценарии там может возникнуть NullPointerException, маскирующий исходную ошибку или ошибку формирования диагностического объекта.

Вариант с прямым throw value прост, но не различает отсутствующее значение и настоящее исключение. Вариант с throw new IllegalStateException("Причина отсутствует") даёт более понятное сообщение, но требует выбрать семантику ошибки и может потерять исходный контекст.

Практически предпочтительна явная проверка: если отсутствие исключения — ошибка состояния, выбрасывают осмысленное доменное или IllegalStateException; если отсутствие допустимо, исключение вообще не выбрасывают. Такой подход делает причину сбоя явной и упрощает поиск ошибки по логам.

Что кандидаты часто упускают

1. Вопрос: Можно ли заменить catch (NullPointerException) на catch (Exception) в этом примере?

   Ответ: Да. NullPointerException наследуется от RuntimeException, а тот — от Exception, поэтому обработчик catch (Exception) также перехватит исключение. Однако он менее специфичен и может скрыть другие ошибки; обычно предпочтительнее перехватывать конкретный ожидаемый тип.

2. Вопрос: Требует ли throw null объявления throws у метода?

   Ответ: Нет. Фактически возникает NullPointerException, то есть непроверяемое исключение. Компилятор не требует объявлять или обрабатывать подклассы RuntimeException, даже если они выбрасываются явно или возникают автоматически.

3. Вопрос: Будет ли catch (Throwable e) перехватывать результат throw null?

   Ответ: Да. Возникший NullPointerException является объектом Throwable, поэтому обработчик его поймает. Но перехват всего Throwable обычно слишком широк: он включает не только обычные исключения, но и серьёзные ошибки JVM из иерархии Error, которые часто не следует скрывать или продолжать после них работу.