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

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

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

Явная обработка ошибок через match позволяет точно контролировать каждую ветвь, но при последовательном выполнении множества операций приводит к повторяющемуся коду преобразования и досрочного возврата ошибки. Связка Result, оператора ? и трейта From решает эту проблему композиции: отдельные функции могут сообщать специализированные ошибки, а функция более высокого уровня — собирать их в единый тип.

Такой подход сохраняет проверяемость на этапе компиляции. Преобразования не выбираются по именам или тексту ошибки: компилятор проверяет конкретные реализации трейта.

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

Предположим, функция читает файл и затем разбирает его содержимое как число. Чтение может завершиться std::io::Error, а разбор — std::num::ParseIntError, тогда как публичный интерфейс функции должен возвращать единый тип ошибки приложения.

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

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

Для Result<T, E> оператор ? пропускает успешное значение дальше. При Err(source) он прекращает выполнение текущей функции и возвращает ошибку, предварительно преобразовав её в ожидаемый тип ошибки через From::from(source).

Упрощённо механизм можно представить так: если операция возвращает Result<T, E1>, а текущая функция возвращает Result<_, E2>, то для применения ? требуется E2: From<E1>. В современном Rust это реализовано через общий механизм Try и FromResidual, но для обычного Result практическое правило остаётся тем же.

use std::{fs, num::ParseIntError};

#[derive(Debug)]
enum AppError {
    Io(std::io::Error),
    InvalidNumber(ParseIntError),
}

impl From<std::io::Error> for AppError {
    fn from(error: std::io::Error) -> Self { Self::Io(error) }
}

impl From<ParseIntError> for AppError {
    fn from(error: ParseIntError) -> Self { Self::InvalidNumber(error) }
}

fn load_port(path: &str) -> Result<u16, AppError> {
    let text = fs::read_to_string(path)?;
    Ok(text.trim().parse()?)
}

В первом применении ? std::io::Error преобразуется в AppError::Io, во втором ParseIntError — в AppError::InvalidNumber. Исходная ошибка сохраняется внутри варианта перечисления, поэтому вызывающий код может выполнить сопоставление и принять разное решение для каждой причины.

Автоматическое преобразование не означает, что Rust найдёт любой подходящий способ конвертации. Нужен именно доступный From<E1> for E2; Into логически связан с From, но для требования оператора ? обычно проектируют и проверяют преобразование через From. Нельзя произвольно добавить реализацию для двух внешних типов из-за правил согласованности реализаций, поэтому собственный тип ошибки приложения обычно объявляют в своём crate.

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

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

Сервис загружает конфигурацию из файла: сначала возможна ошибка доступа к файлу, затем ошибка синтаксического разбора числового параметра. Рассматривались три варианта.

Первый — возвращать Box<dyn Error>. Это быстро объединяет разные ошибки и удобно для небольшого CLI-инструмента, но усложняет точное сопоставление причин и делает контракт менее явным.

Второй — вручную преобразовывать каждую ошибку через map_err. Такой вариант даёт полный локальный контроль, однако повторяет шаблонный код и повышает риск случайно потерять исходную ошибку.

Третий — определить AppError с отдельными вариантами и реализовать From для ошибок нижнего уровня. Это выбранное решение: ? сохраняет краткость функции, тип явно описывает контракт, а верхний слой может отдельно обработать отсутствие файла, отказ в доступе и некорректное содержимое. В результате диагностика остаётся детальной, а код чтения конфигурации не перегружен техническими ветвлениями.

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

Всегда ли ? требует ручной реализации From для одинаковых типов ошибок?

Нет. Если тип ошибки операции уже совпадает с типом ошибки возвращаемого Result, преобразование не требует пользовательской реализации. Например, операция с Result<T, AppError> может использовать ? внутри функции, возвращающей Result<_, AppError>, напрямую. Реализация From нужна именно при переходе между различными типами.

Можно ли с помощью From преобразовать ошибку в строку без потери информации?

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

Что произойдёт, если для одного исходного типа подходят несколько преобразований?

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