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

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

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

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

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

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

Представим функцию загрузки конфигурации. Она может завершиться из-за ошибки чтения, отсутствия обязательного параметра или некорректного номера порта.

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

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

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

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

use std::{error::Error, fmt};

#[derive(Debug)]
enum ConfigError {
    Io(std::io::Error),
    InvalidPort(String),
}

impl fmt::Display for ConfigError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            Self::Io(_) => write!(f, "ошибка чтения конфигурации"),
            Self::InvalidPort(v) => write!(f, "некорректный порт: {v}"),
        }
    }
}

impl Error for ConfigError {}

Теперь вызывающий код может отдельно обработать Io и InvalidPort, не разбирая текст. При этом Display отвечает за сообщение человеку, а структура типа — за машинно проверяемую логику.

В реальном коде для исходной ошибки обычно реализуют метод source, чтобы сохранить цепочку причин. Для преобразования нижнеуровневых ошибок в собственный тип применяют явные реализации From или средства вроде атрибута from в библиотеке thiserror; это упрощает использование оператора ?, но не отменяет необходимости спроектировать варианты ошибки.

Box<dyn Error> удобен на границах приложений или в небольших обобщённых слоях, однако он скрывает конкретные варианты от вызывающего кода. String ещё проще, но подходит главным образом для прототипов, конечного отображения сообщения или случаев, где программная реакция на конкретную причину не требуется.

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

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

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

Вариант со строковыми ошибками прост в реализации, но требует поиска фраз в сообщениях и не различает причины надёжно. Box<dyn Error> сохраняет цепочку источников и уменьшает связанность, но не позволяет удобно принять разные решения без downcast или дополнительных соглашений.

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

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

Достаточно ли перечисления вариантов, если оно не сохраняет исходную ошибку?

Нет, не всегда. Вариант вроде Io сообщает категорию сбоя, но без исходного std::io::Error теряются код ОС, путь и исходное диагностическое сообщение. Если эти сведения нужны для журналирования или решения о повторной попытке, их следует сохранить и корректно связать через source.

Почему нельзя сделать все варианты ошибки публичными деталями каждого внутреннего слоя?

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

Когда String всё же является приемлемым типом ошибки?

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