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

Компилятор потребует обработать ошибку непосредственно внутри блока defer. Даже если окружающая функция объявлена с throws, ошибка из defer не может быть выброшена наружу через этот блок.

Обычно используют локальный do-catch, try? с осознанным подавлением ошибки или заменяют операцию на небросающую. Выбор зависит от того, можно ли безопасно проигнорировать сбой очистки.

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

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

При этом defer выполняется уже в процессе выхода из области видимости. Поэтому его тело не должно неожиданно менять способ завершения функции или заменять исходную ошибку другой ошибкой.

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

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

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

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

Тело defer должно самостоятельно обработать результат бросающей операции. Объявление внешней функции с throws этого требования не отменяет.

enum CleanupError: Error { case failed }

func closeResource() throws {
    throw CleanupError.failed
}

func work() throws {
    defer {
        do {
            try closeResource()
        } catch {
            print("cleanup failed")
        }
    }
}

Здесь ошибка closeResource() перехватывается внутри defer, поэтому work() может завершиться штатно или передать наружу только свою основную ошибку. Вариант try? допустим, если сбой очистки действительно не требует реакции; иначе он скрывает диагностически важную информацию.

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

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

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

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

Для обычного временного файла разумным выбором будет локальный do-catch с журналированием. Основная ошибка записи сохраняется, а сбой очистки не маскирует исходную причину и остаётся доступным для мониторинга.

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

Дополнительный вопрос 1: Можно ли объявить внешнюю функцию с throws, чтобы разрешить бросающую операцию в defer?

Нет. throws внешней функции позволяет выбрасывать ошибки из её обычного тела, но не превращает тело defer в канал передачи ошибки. Операция внутри defer всё равно должна быть обработана локально.

Дополнительный вопрос 2: Что произойдёт с основной ошибкой, если ошибка очистки будет подавлена через try??

Основная ошибка сохранится и сможет быть передана вызывающему коду, если она возникла вне defer. Ошибка очистки при этом исчезнет с точки зрения вызывающего кода, поэтому try? следует применять только когда её потеря допустима.

Дополнительный вопрос 3: Как передать вызывающему коду одновременно основную ошибку и ошибку очистки?

Нельзя рассчитывать на автоматическое объединение ошибок в defer. Нужно явно собрать обе причины в собственный тип ошибки, структуру диагностики или отдельный результат, причём это обычно требует управлять очисткой до окончательного завершения функции, а не скрывать её внутри безусловного defer.