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

При повторном выбрасывании того же объекта исключения сохраняется стек вызовов, записанный в момент создания этого объекта. Операция throw сама по себе стек не обновляет, поэтому диагностика укажет исходное место возникновения исключения, а не место повторного выбрасывания.

Если вместо повторного выбрасывания создать новое исключение, у нового объекта будет собственный стек — от места его создания. Исходную ошибку можно сохранить как cause, чтобы не потерять первоначальный стек.

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

Стек вызовов в Java предназначен для восстановления пути выполнения программы при ошибке: он показывает последовательность методов от места создания исключения до внешнего обработчика. Такой подход позволяет диагностировать не только тип ошибки, но и контекст, в котором она возникла.

Поэтому объект Throwable хранит трассировку как состояние самого объекта. Повторная передача этого объекта между слоями не должна искажать исходную точку возникновения ошибки.

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

Исключение часто проходит через несколько слоёв приложения: низкоуровневый код обнаруживает ошибку, сервис добавляет контекст, а внешний слой регистрирует её или преобразует в ответ API. Если при этом без необходимости заменять объект исключения, можно потерять исходное место сбоя или получить несколько не связанных друг с другом стеков.

Обратная крайность также опасна: повторное выбрасывание того же объекта сохраняет технический тип и исходный стек, но не добавляет бизнес-контекст. Нужно отличать сохранение исходной диагностики от осознанного создания нового исключения на границе абстракции.

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

Стек вызовов обычно фиксируется при создании объекта Throwable, например внутри конструктора исключения. Команда throw меняет управление, но не создаёт новый объект и не вызывает повторную фиксацию стека.

public class Demo {
    static void lowLevel() {
        throw new IllegalStateException("disk error");
    }

    static void service() {
        try {
            lowLevel();
        } catch (IllegalStateException e) {
            throw e;
        }
    }

    public static void main(String[] args) {
        try {
            service();
        } catch (IllegalStateException e) {
            e.printStackTrace();
        }
    }
}

В примере service() повторно выбрасывает тот же объект. Его стек начинается с места создания исключения в lowLevel(), а вызовы service() и main() отображаются как последующие кадры стека. Сам факт повторного throw e не заменяет исходный стек.

При создании оболочки, например new ServiceException("...", e), новый объект получает стек с места создания оболочки. Поле cause при этом сохраняет ссылку на исходное исключение и его стек. Такой вариант полезен, когда нужно заменить техническую абстракцию на доменную, но сохранить первопричину.

Метод fillInStackTrace() явно перезаписывает трассировку текущего объекта текущим стеком. Это специальный механизм, а не обычный эффект throw; его применение может ухудшить диагностику, если исходный стек был важен. Кроме того, сбор и печать трассировки имеют стоимость, поэтому исключения не следует использовать как обычный механизм управления успешным потоком.

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

Сервис чтения файла получает FileNotFoundException и должен сообщить вызывающему слою, что не найден обязательный шаблон конфигурации. Рассматривались два варианта: повторно выбросить исходное исключение или создать доменное исключение с исходной ошибкой в cause.

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

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

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

Что произойдёт со стеком, если исключение перехватить, вызвать у него fillInStackTrace(), а затем выбросить снова?

fillInStackTrace() заменит сохранённую трассировку стеком текущего места вызова. Последующий throw будет использовать уже обновлённый стек, поэтому первоначальное место создания может исчезнуть из основной трассировки. Такой вызов допустим только при осознанной необходимости, например при переиспользовании специального объекта исключения; для обычной обработки ошибок он обычно не нужен.
Как будет выглядеть диагностика при создании нового исключения без передачи исходной причины?

Новое исключение получит стек от места собственного создания, но связи с исходным исключением не будет. В результате теряются тип, сообщение и стек первичной ошибки, если они отдельно не сохранены. При преобразовании ошибки следует передавать исходный объект как cause, иначе журнал часто показывает только вторичный симптом.
Меняется ли стек при передаче исключения между потоками?

Нет, смена потока сама по себе не изменяет стек, сохранённый в объекте исключения. Если один поток передал объект другому, а второй его выбросил, диагностика всё равно отражает место создания объекта, а не место передачи или повторного выбрасывания. Это может затруднить анализ конкурентного кода, поэтому к сообщению и журналу иногда добавляют сведения о потоке и операции, не подменяя исходную трассировку.