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

Выберите Result::map. Он применяет переданную функцию только к значению внутри Ok, преобразует его тип и оставляет Err без изменений.

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

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

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

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

Допустим, операция вернула Result<T, E>, а вызывающему коду нужен другой успешный тип U. Ошибка при этом уже содержит подходящую информацию и не должна быть заменена или обработана на текущем шаге.

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

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

Метод map имеет концептуальную форму преобразования Result<T, E> в Result<U, E>. Если исходное значение — Ok(value), вызывается функция преобразования и её результат помещается в новый Ok. Если исходное значение — Err(error), функция не вызывается, а ошибка возвращается без изменения.

use std::num::ParseIntError;

struct UserId(u64);

fn parse_user_id(text: &str) -> Result<UserId, ParseIntError> {
    text.parse::<u64>().map(UserId)
}

В примере parse возвращает Result<u64, ParseIntError>, а map преобразует только u64 в UserId. Тип ошибки ParseIntError и конкретное значение ошибки сохраняются.

map не выполняет вложенное распрямление. Если функция преобразования сама возвращает Result, получится Result<Result<U, E2>, E>. Для последовательной операции, которая может завершиться новой ошибкой, нужен and_then. Для изменения типа ошибки используется map_err.

Метод потребляет исходный Result, поэтому значение внутри него обычно перемещается в замыкание. Если нужно преобразовать заимствованное значение без перемещения исходного объекта, сначала применяют подходящий метод заимствования, например as_ref.

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

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

Вариант с ручным match даёт полный контроль, но добавляет шаблонный код. map_err здесь не подходит: он изменяет ошибку, хотя проблема находится в успешном значении. and_then избыточен, поскольку преобразование u64 в UserId не возвращает новую ошибку.

Выбор map сохраняет исходную ошибку, делает тип идентификатора явным и оставляет обработку сбоя вызывающему слою. В результате ошибки разбора по-прежнему можно классифицировать там, где принимается решение о HTTP-ответе.

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

Вызывается ли функция map, если исходный результат содержит Err?

Нет. Замыкание получает только значение из Ok; при Err оно не вызывается. Поэтому побочные эффекты внутри замыкания не происходят для ошибочного результата. Это делает map безопасным для преобразований, которые должны выполняться только после успешного завершения предыдущего шага.

Что произойдёт, если функция внутри map сама возвращает Result?

Возникнет вложенный тип вроде Result<Result<U, E2>, E>. map считает результат замыкания обычным новым успешным значением и не анализирует его структуру. Если нужно передать внутреннюю ошибку наружу, применяют and_then, который выполняет преобразование с последующим распрямлением одного уровня.

Чем map отличается от map_or с точки зрения сохранения ошибки?

map возвращает Result и сохраняет ошибку. map_or вместо этого извлекает окончательное значение другого типа: для Ok применяет функцию, а для Err использует значение по умолчанию, поэтому информация об ошибке теряется. Выбор зависит от границы API: если вызывающий код ещё должен обработать сбой, нужен map; если ошибка уже превращается в допустимое значение по умолчанию, возможен map_or.