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

Closeable объявляет close() с проверяемым исключением IOException, а AutoCloseable допускает более общий Exception. Поэтому при использовании ресурса через тип AutoCloseable вызывающий код обычно должен обработать или объявить Exception, тогда как для Closeable достаточно обработки или объявления IOException. Это определяется статическим типом ресурса на этапе компиляции, а не фактическим классом объекта.

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

Closeable появился как специализированный контракт для потоков ввода-вывода, где основной ожидаемый сбой при закрытии — IOException. Позднее в Java 7 появился общий интерфейс AutoCloseable вместе с конструкцией try-with-resources, чтобы автоматически освобождать не только файлы и потоки, но и любые ресурсы: соединения, транзакции, блокировки и другие объекты с операцией закрытия.

Общий контракт не мог ограничиться только IOException, поэтому AutoCloseable.close() объявляет Exception. Реализация при этом вправе сузить список проверяемых исключений или вообще не выбрасывать их.

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

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

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

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

У Closeable метод close() имеет контракт вида throws IOException. У AutoCloseable тот же метод может объявлять throws Exception. Поскольку Closeable является подинтерфейсом AutoCloseable, его контракт совместим с более общим контрактом родителя.

import java.io.Closeable;
import java.io.IOException;

class Demo {
    static class Resource implements Closeable {
        @Override public void close() throws IOException { }
    }

    static void viaCloseable() throws IOException {
        try (Closeable r = new Resource()) { }
    }

    static void viaAutoCloseable() throws Exception {
        try (AutoCloseable r = new Resource()) { }
    }
}

В первом методе компилятор видит Closeable.close() и требует учитывать IOException. Во втором он видит только AutoCloseable.close() и требует учитывать Exception, хотя фактический объект тот же и его метод объявляет лишь IOException.

Это именно статический анализ: во время выполнения вызывается переопределённый метод реального объекта. Если close() выбросит исключение, оно будет обработано правилами try-with-resources; выбор интерфейса не меняет динамическую диспетчеризацию.

Реализация может сузить исключения ещё сильнее. Например, класс может реализовать AutoCloseable и объявить close() без throws, но ссылка типа AutoCloseable всё равно сохраняет для компилятора общий контракт Exception. Для более точного анализа следует использовать конкретный тип ресурса, Closeable или локальный вывод типа var, если это не ухудшает читаемость.

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

Сервис работал с объектом, освобождающим сетевое соединение. Разработчик объявил переменную как AutoCloseable, из-за чего простой метод стал требовать throws Exception. Варианты решения были такими:

добавить throws Exception — быстро, но слишком широко и слабо документирует реальные сбои;
перехватить Exception — позволяет продолжить работу, но может скрыть ошибки, не связанные с закрытием;
использовать точный тип ресурса или специализированный интерфейс — лучше отражает контракт и сохраняет контроль над обработкой.

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

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

1. Станет ли требование throws Exception уже, если реализация AutoCloseable.close() не объявляет исключений?

Нет, если ресурс используется через ссылку типа AutoCloseable. Компилятор анализирует доступный статический контракт этой ссылки и видит throws Exception. Если же ресурс имеет конкретный статический тип без проверяемых исключений или тип выводится как конкретный через var, требование может стать уже.

Это не означает, что во время выполнения обязательно возникнет Exception; речь только о проверке потенциальных проверяемых исключений компилятором.

2. Можно ли использовать Closeable для любого ресурса, чтобы получить более узкий контракт?

Технически класс может реализовать Closeable, но это корректно только тогда, когда ресурс действительно соответствует семантике закрываемого объекта ввода-вывода и его ошибки естественно выражаются через IOException. Для транзакций, блокировок или клиентских сессий такой выбор может вводить пользователей API в заблуждение.

Лучше определить собственный интерфейс или реализовать AutoCloseable, объявив доменное проверяемое исключение. Узкий контракт полезен только тогда, когда он правдиво описывает поведение ресурса.

3. Обязан ли метод объявлять Exception, если AutoCloseable.close() выбрасывает только непроверяемое исключение?

Нет. Непроверяемые исключения — наследники RuntimeException и Error — не требуют обязательного catch или throws, даже если ресурс имеет тип AutoCloseable. Объявление throws Exception в интерфейсе означает потенциально проверяемые исключения, но не превращает непроверяемое исключение в проверяемое.

При этом такое исключение всё равно может завершить выполнение метода. Автоматическое закрытие ресурса не подавляет его само по себе; его дальнейшая судьба определяется общими правилами обработки исключений в конструкции try-with-resources.