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

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

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

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

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

Именно эту задачу решает цепочка источников, поддерживаемая трейтом std::error::Error. Она отделяет пользовательское сообщение от структурированной информации о первоначальной ошибке.

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

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

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

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

Создайте тип ошибки библиотеки с полем для контекста и полем source для исходной ошибки. В реализации std::error::Error метод source должен возвращать ссылку на вложенную ошибку.

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

#[derive(Debug)]
struct ConfigError {
    message: String,
    source: std::io::Error,
}

impl fmt::Display for ConfigError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}: {}", self.message, self.source)
    }
}

impl Error for ConfigError {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        Some(&self.source)
    }
}

fn load() -> Result<(), ConfigError> {
    std::fs::read("app.cfg")
        .map(|_| ())
        .map_err(|source| ConfigError {
            message: "не удалось прочитать конфигурацию".into(),
            source,
        })
}

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

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

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

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

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

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

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

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

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

Достаточно ли сохранить текст исходной ошибки в поле message?

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

Добавляет ли оператор ? контекст к каждой распространяемой ошибке?

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

Когда собственный enum ошибки лучше универсального типа ошибки?

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

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