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

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

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

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

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

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

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

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

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

Тип функции включает её способность выбрасывать ошибку. Тип () -> Void означает, что функция не выбрасывает ошибку, а () throws -> Void допускает такой путь завершения.

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

func safeOperation() {}
func riskyOperation() throws {}

run(safeOperation)       // Допустимо
// run(riskyOperation)   // Нужен параметр, допускающий throws

При передаче safeOperation в run контракт расширяется только на уровне контекста вызова: вызывающий код готов к ошибке, хотя конкретная функция её не создаёт. При передаче riskyOperation в параметр типа () -> Void компилятор не может гарантировать обработку ошибки, поэтому такое преобразование запрещается.

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

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

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

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

Вариант с изменением параметра на throwing сохраняет информацию об ошибке и передаёт ответственность вызывающему коду. Минус — меняется контракт API и все места вызова должны использовать обработку ошибок.

Для библиотечного API обычно выбирают throwing-параметр, если ошибка является значимой частью поведения. Для внутреннего callback, где ошибка действительно должна быть поглощена, допустим явный адаптер с документированным преобразованием ошибки.

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

Является ли throws частью типа функции?

Да. Функции с типами () -> Int и () throws -> Int различаются по контракту, даже если у них одинаковые параметры и результат. Поэтому их нельзя свободно присваивать друг другу.

Можно ли throwing-функцию передать в параметр, объявленный с rethrows?

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

Можно ли безопасно убрать throws, если известно, что конкретный вызов ошибки не выбросит?

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