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

В обычном Swift throws не указывает конкретный тип ошибки в сигнатуре функции: вызывающий код получает значение типа any Error. У Result тип ошибки является частью самого типа, поэтому Result<Value, Failure> явно фиксирует Failure на уровне API и позволяет компилятору проверять его использование.

В версиях Swift с поддержкой typed throws это ограничение throws частично снимается: функция может объявить конкретный тип ошибки. Однако Result по-прежнему удобен, когда ошибку нужно передавать как обычное значение, хранить или комбинировать без немедленного catch.

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

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

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

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

Предположим, API объявляет только throws. По его сигнатуре нельзя понять, какие именно причины сбоя являются штатными: ошибка сети, недействительные данные или отсутствие разрешений. Вызывающий код вынужден либо анализировать варианты через catch, либо обрабатывать неизвестный Error обобщённо.

Если API возвращает Result<Value, Failure>, конкретный тип Failure виден сразу. Неверный вариант ошибки нельзя незаметно подставить в такой результат без преобразования типов, поэтому контракт становится более проверяемым, особенно при построении слоёв приложения.

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

В обычной форме throws типизирует только факт возможности ошибки, но не её конкретный тип:

import Foundation

enum LoadError: Error {
    case offline
}

func load() throws -> String {
    throw LoadError.offline
}

func loadResult() -> Result<String, LoadError> {
    .failure(.offline)
}

Для load() вызывающий код работает с any Error; конкретный тип можно определить сопоставлением в catch, но он не закреплён в сигнатуре. Для loadResult() тип ошибки — LoadError, поэтому доступные варианты известны статически, а значение ошибки можно передать как данные.

Это не означает, что Result всегда лучше. throws обычно проще для последовательного кода: ошибка автоматически поднимается по стеку вызовов, а успешное значение остаётся обычным возвращаемым значением. Result удобнее на границах асинхронных или событийных API, но при большом количестве преобразований может привести к явной цепочке обработки success и failure.

В Swift с typed throws можно объявить конкретный тип ошибки непосредственно у бросающей функции. Это уменьшает различие в типобезопасности между throws и Result, но не отменяет различия в модели передачи: throws использует управление потоком и do-catch, а Result — обычное значение.

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

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

Можно возвращать Result<Profile, ProfileError>. Плюс такого решения — явный тип ошибки и возможность сохранить результат до момента, когда UI или другой слой будет готов его обработать. Минус — необходимость явно преобразовывать или сопоставлять Result при каждом переходе между слоями.

Можно использовать обычный throws, а доменный тип ошибки документировать и проверять через catch. Это делает код короче, но компилятор не заставляет вызывающий код различать варианты. Для границы между сетевым слоем и состоянием экрана выбран Result, потому что результат передаётся через хранилище состояния и обрабатывается позже; внутри последовательной бизнес-операции остаётся throws.

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

1. Вопрос: Делает ли Result обработку ошибки обязательной?

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

2. Вопрос: Можно ли преобразовать Result<Value, SpecificError> в Result<Value, any Error> без изменения успешного значения?

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

3. Вопрос: Какой подход выбрать, если функция вызывается в длинной последовательной цепочке операций?

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