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

Да, невыбрасывающее замыкание можно передать туда, где ожидается замыкание с throws. Оно считается совместимым с более общим типом, потому что гарантирует как минимум то, что требуется вызывающему коду: операцию можно вызвать через try, хотя фактически она ошибку не выбрасывает.

Обратное преобразование невозможно: замыкание с throws нельзя передать в API, ожидающее невыбрасывающую функцию, поскольку вызывающий код не обязан обрабатывать возможную ошибку.

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

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

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

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

Представим API, которое принимает операцию типа () throws -> Void. Если передать ему обычное замыкание, возникает вопрос: не нарушает ли это контракт выбрасывающей функции?

Неверное понимание направления совместимости приводит к лишним обёрткам либо к попытке подавить ошибку через try!. Особенно опасна обратная ситуация: передача выбрасывающего замыкания в невыбрасывающий API создала бы путь к необработанной ошибке.

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

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

func execute(_ operation: () throws -> Void) throws {
    try operation()
}

let work: () -> Void = {
    print("готово")
}

try execute(work)

Вызов execute(work) корректен. Внутри execute сохраняется синтаксис try, потому что сам параметр имеет выбрасывающий тип, но конкретное переданное замыкание фактически не может завершиться ошибкой.

Направление нельзя поменять без явной обработки ошибки. Если операция имеет тип () throws -> Void, её нужно либо передать в другой выбрасывающий контекст, либо обернуть в do-catch, преобразовать в Result или осознанно использовать try? с потерей информации об ошибке.

Важно отличать совместимость типов от поведения конкретного вызова. Наличие throws в типе параметра не означает, что каждый переданный обработчик действительно выбросит ошибку; оно означает, что API готов корректно работать с таким сценарием.

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

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

Выбран API с параметром () throws -> Void, потому что он покрывает оба случая: обычные замыкания передаются напрямую, а выбрасывающие вызывающий код обязан обработать. Результат — единая точка выполнения без небезопасного подавления ошибок и без дублирования методов.

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

Нужно ли писать try при передаче невыбрасывающего замыкания в выбрасывающий параметр?

При передаче самого замыкания try не нужен: передаётся значение функции. try требуется при вызове выбрасывающей функции, например try execute(work), если execute объявлена с throws. Причина в том, что ошибка может возникнуть внутри execute, даже если конкретный обработчик её не выбрасывает.
Можно ли автоматически передать выбрасывающее замыкание в API с параметром () -> Void?

Нет. Такой API не предоставляет контекста для обработки ошибки. Нужно изменить сигнатуру API на () throws -> Void либо явно перехватить ошибку внутри адаптирующего замыкания и определить, что делать: вернуть состояние, залогировать проблему, преобразовать её или завершить выполнение другим способом.
Меняется ли результат операции из-за того, что невыбрасывающее замыкание принято как выбрасывающее?

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