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

Неполное сопоставление с Result приводит к ошибке компиляции: конструкция match должна покрывать оба варианта — Ok и Err. Это гарантирует, что ветка обработки успешного результата или ошибки не будет случайно пропущена.

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

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

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

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

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

Rust останавливает такую ошибку на этапе компиляции. Однако использование обобщённой ветки _ формально закрывает все варианты, поэтому сама по себе полнота сопоставления ещё не означает содержательной обработки ошибки.

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

Result — это перечисление с двумя вариантами: Ok(T) и Err(E). При сопоставлении через match компилятор анализирует шаблоны и проверяет, покрыты ли оба варианта.

use std::num::ParseIntError;

fn parse_number(text: &str) -> Result<u32, ParseIntError> {
    let number = match text.parse::<u32>() {
        Ok(value) => value,
        Err(error) => return Err(error),
    };
    Ok(number)
}

В этом примере ошибка явно возвращается вызывающему коду. Если удалить ветку Err, компилятор сообщит о неполном сопоставлении. Если заменить её на _, компиляция пройдёт, но ошибка может быть отброшена или обработана слишком грубо.

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

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

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

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

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

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

Дополнительный вопрос 1: достаточно ли ветки _ для безопасной обработки Result?

Нет. Ветка _ делает сопоставление исчерпывающим только формально. Она может скрыть ошибку, потому что одинаково обработает все непредусмотренные варианты и отбросит различия между ними. Безопасность зависит от логики ветки, а не только от отсутствия ошибки компиляции.

Дополнительный вопрос 2: что произойдёт при добавлении нового варианта в пользовательское перечисление ошибки?

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

Дополнительный вопрос 3: чем исчерпывающее сопоставление Result отличается от проверки ошибки во время выполнения?

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