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

Обычно нет: Option и Result имеют разные типы остаточного результата, поэтому оператор ? не может автоматически превратить None в ошибку Result. Сначала нужно явно определить, какую ошибку означает отсутствие значения, например преобразовать Option<T> в Result<T, E> через ok_or или ok_or_else.

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

Option предназначен для ситуации «значение может отсутствовать», когда отсутствие само по себе не является ошибкой. Result разделяет успешный результат и причину сбоя, поэтому его используют, когда вызывающему коду нужно обработать ошибку или понять её причину.

Оператор ? был введён как краткий способ раннего выхода при неуспешном результате. При этом Rust сохраняет строгую типизацию: язык не угадывает, какую ошибку нужно создать из None.

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

Представим функцию загрузки обязательного идентификатора. Внутренний API поиска возвращает Option<u64>, потому что отсутствие записи для него нормально, а внешняя функция возвращает Result, поскольку отсутствие идентификатора считается ошибкой запроса.

Если попытаться передать Option через ? напрямую, код не скомпилируется: у None нет значения ошибки, которое можно вернуть как Err. Если бездумно использовать unwrap, отсутствие записи превратится в panic, хотя это штатная ошибка входных данных или состояния системы.

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

Нужно явно задать границу между двумя моделями неуспеха: преобразовать Option<T> в Result<T, E>, а затем применить ? к уже преобразованному значению.

fn load_id() -> Result<u64, &'static str> {
    let found: Option<u64> = Some(42);
    let id = found.ok_or("идентификатор не найден")?;
    Ok(id)
}

ok_or создаёт Err с переданным значением, если получен None, а при Some извлекает значение. После этого ? работает с Result: при Ok передаёт u64 дальше, при Err немедленно возвращает ошибку из load_id.

Если создание ошибки дорогое или требует вычислений, предпочтителен ok_or_else: замыкание будет вызвано только при None. Тип ошибки должен соответствовать возвращаемому Result либо поддерживать явное преобразование, например через map_err.

В стандартных сценариях нельзя ожидать автоматического преобразования None в произвольный Err: у компилятора нет достоверного способа выбрать текст, тип или контекст ошибки. Явное преобразование делает контракт функции понятным и не скрывает семантическое решение.

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

Сервис получает необязательный результат поиска пользователя, но для выполнения операции пользователь обязателен. Возможный вариант — вызвать unwrap: это коротко, но аварийно завершит текущий поток при обычном отсутствии пользователя. Другой вариант — изменить возвращаемый тип на Option, однако тогда теряется возможность сообщить вызывающему коду причину отказа и согласовать её с другими ошибками сервиса.

Выбранное решение — преобразовать None в доменную ошибку до применения ?. Такой подход сохраняет ранний выход, позволяет централизованно классифицировать ошибку и не использует panic для ожидаемого сценария. В результате отсутствие пользователя обрабатывается как контролируемый отказ, а не как дефект программы.

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

Вопрос: Можно ли преобразовать None в Err с помощью From автоматически?

Ответ: Сам по себе оператор ? не выбирает произвольное значение ошибки для None. Обычно преобразование выполняют явно через ok_or или ok_or_else; эти методы требуют, чтобы вызывающий код предоставил ошибку. Механизм преобразования ошибок через From полезен уже после того, как имеется Result с конкретным типом ошибки.
Вопрос: Чем ok_or отличается от ok_or_else в этом сценарии?

Ответ: ok_or получает готовое значение ошибки, которое вычисляется до вызова метода. ok_or_else получает замыкание и вычисляет ошибку только при None. Поэтому ok_or_else предпочтителен, если построение ошибки затратно, требует форматирования или может иметь побочные эффекты.
Вопрос: Почему замена Option на Result внутри функции не всегда является улучшением дизайна?

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