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

Преобразование через ok_or превращает Some(value) в Ok(value), а None — в Err(error). Вызывающий код получает явную причину отказа в виде значения ошибки и может использовать оператор ?, но сама причина отсутствия не восстанавливается: она задаётся аргументом ok_or.

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

В Rust Option и Result разделяют два разных состояния: отсутствие значения и ошибку операции. Это позволяет не смешивать нормальный сценарий вроде «настройка не задана» с отказом вроде «настройка имеет неверный формат».

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

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

Представим поиск обязательного заголовка HTTP-запроса. Метод извлечения заголовка возвращает Option, потому что заголовок может отсутствовать как допустимое состояние API, но обработчику нужно сообщить вызывающему коду конкретную ошибку запроса.

Если оставить None до конца цепочки, вызывающий код не узнает, почему операция не выполнена. Если использовать unwrap, отсутствие заголовка приведёт к panic, что неверно для ожидаемой ошибки внешнего ввода.

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

ok_or выполняет преобразование по простой схеме: успешное значение Some(T) становится Ok(T), а None становится Err(E), где E — переданная ошибка. После этого значение участвует в обычной цепочке обработки Result и может быть возвращено наружу через ?.

fn require_header(value: Option<&str>) -> Result<&str, String> {
    value.ok_or_else(|| "заголовок отсутствует".to_owned())
}

fn handle(value: Option<&str>) -> Result<usize, String> {
    let header = require_header(value)?;
    Ok(header.len())
}

В исходном Option различимы только Some и None. Поэтому преобразование не извлекает скрытую причину отсутствия, а назначает её в момент вызова. Если несколько разных причин уже были сведены к None, через ok_or их различить невозможно.

ok_or принимает готовое значение ошибки, а ok_or_else — замыкание, вычисляемое только при None. Ленивый вариант предпочтительнее, если создание ошибки дорогое, требует форматирования или имеет побочные вычисления. Ошибка должна описывать ожидаемый отказ операции, а не маскировать программный инвариант, нарушение которого действительно может требовать panic.

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

В HTTP-сервисе обязательный идентификатор пользователя извлекается как Option. Рассматривались три варианта: вернуть None и заставить каждый вызывающий слой повторять проверку; вызвать unwrap, что может обрушить обработчик на некорректном запросе; преобразовать отсутствие в доменную ошибку, например «не указан идентификатор».

Выбран третий вариант. На границе обработки запроса Option преобразуется в Result, ошибка преобразуется в корректный ответ клиента, а внутренние функции получают обычный контракт с обязательным значением. Это сохраняет проверяемость, не допускает аварийного завершения из-за пользовательского ввода и централизует описание причины отказа.

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

Чем ok_or отличается от ok_or_else?

ok_or получает уже вычисленное значение ошибки, поэтому выражение для него вычисляется независимо от того, находится ли внутри Option значение. ok_or_else получает замыкание и вызывает его только при None; это важно для дорогого форматирования, выделения памяти или вычисления контекста.
Можно ли через ok_or различить несколько причин None?

Нет, если исходный Option уже объединил эти причины в одно состояние None. ok_or может назначить только одну ошибку этому состоянию. Если причины важны для API, их нужно моделировать раньше: возвращать Result<Option<T>, E> либо использовать более выразительный тип состояния.
Почему преобразование Option в Result лучше выполнять на границе операции, а не сразу после получения значения?

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