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

Если тело try завершилось нормально, но close() выбросил исключение, именно это исключение станет основным и будет передано дальше или обработано в catch. Подавленные исключения появляются только у последующих операций закрытия, если закрывается несколько ресурсов.

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

Try-with-resources появился в Java 7, чтобы автоматически освобождать ресурсы и устранить повторяющийся шаблон с ручным вызовом close() в finally. Исходная проблема заключалась в том, что ручное закрытие легко забыть, а ошибка закрытия могла потерять исходную ошибку из тела операции.

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

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

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

Особенно важен случай с несколькими ресурсами. Ошибка закрытия одного ресурса не должна препятствовать попытке закрыть остальные, но дополнительные ошибки закрытия нельзя выбрасывать вместо первой возникшей ошибки.

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

Ресурсы закрываются в порядке, обратном их объявлению. Если тело try не выбросило исключение, первое исключение из close() становится основным. Следующие исключения закрытия добавляются к нему через механизм suppressed exceptions.

Если тело try уже выбросило исключение, оно остаётся основным, а ошибки закрытия становятся подавленными. Таким образом, при нормальном теле основным является сбой очистки, а при аварийном теле — сбой основной операции.

Минимальный пример:

class Demo {
    static class Resource implements AutoCloseable {
        public void close() throws Exception {
            throw new Exception("close failed");
        }
    }

    public static void main(String[] args) {
        try (Resource r = new Resource()) {
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }
}

Будет обработано исключение с сообщением close failed: тело блока завершилось нормально, поэтому другого основного исключения нет.

При нескольких ресурсах Java продолжит закрытие остальных ресурсов даже после ошибки одного close(). Исключения последующих закрытий будут доступны через getSuppressed() у основного исключения. Это позволяет не потерять диагностическую информацию, сохранив при этом однозначный главный сбой.

Практический компромисс состоит в том, что ошибка закрытия может сделать внешне успешную операцию неуспешной. Для файлов это может быть критично: данные могли находиться в буфере и фактически не записаться до закрытия. Поэтому подавлять исключения из close() без анализа допустимо не всегда.

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

Сервис формирует архив и записывает его в файл. Формирование завершилось без исключений, но при закрытии файлового потока произошла ошибка записи буфера.

Вариант с ручным закрытием в finally может случайно скрыть ошибку формирования или привести к сложной логике выбора между двумя исключениями. Ручное игнорирование ошибки close() ещё опаснее: сервис сообщит об успешном создании архива, хотя файл повреждён или записан не полностью.

Выбранное решение — try-with-resources с журналированием основного исключения и его подавленных исключений. В результате ошибка закрытия корректно сигнализирует о неуспешной операции, а при нескольких сбоях диагностика сохраняет все обнаруженные причины.

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

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

Java всё равно попытается закрыть остальные ресурсы в обратном порядке объявления. Исключение первого завершившегося с ошибкой закрытия остаётся основным, а исключения следующих закрытий добавляются к нему как подавленные.
Станет ли исключение из close() подавленным, если тело try завершилось нормально?

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

Не всегда. Для буферизованных потоков закрытие может выполнять финальную запись данных, поэтому исключение из close() означает, что операция могла завершиться неполно. Если контракт метода требует гарантированного сохранения результата, такое исключение нужно передать вызывающему коду или обработать явно, а не игнорировать.