thiserror и anyhow

#[derive(thiserror::Error, Debug)]
enum AppError {
    #[error("не найдено")]
    NotFound,
    #[error("io: {0}")]
    Io(#[from] std::io::Error),
}

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #rs_error_libs1 / 5
   Что генерирует thiserror по атрибутам #[error("...")] и #[from]?

   A)Конструкторы для каждого варианта перечисления

   B)Реализацию Serialize, чтобы ошибку можно было отдать по сети

   C)Логирование каждой созданной ошибки через макрос log

   D)Реализации Display, Error и From для помеченных вариантов

   показать ответ и разбор

   +D)Реализации Display, Error и From для помеченных вариантов

   // разбор: Это derive-макрос вокруг обычного enum: строка из #[error] превращается в Display с подстановкой полей, поле с #[from] даёт реализацию From и попадает в source. Никакого рантайма он не добавляет — на выходе тот же ручной impl, только не написанный руками.

2. #rs_error_libs2 / 5
   Приложение вернуло anyhow::Error, а в одном месте нужно отличить «не найдено» от прочих сбоев. Как быть?

   A)Сравнить текст ошибки со строкой «не найдено»

   B)downcast_ref к конкретному типу ошибки

   C)Никак: anyhow стирает тип безвозвратно

   D)Обернуть вызов в catch_unwind и разобрать причину паники

   показать ответ и разбор

   +B)downcast_ref к конкретному типу ошибки

   // разбор: anyhow не стирает тип, а прячет его за трейт-объектом: downcast_ref::<MyError>() возвращает Some, если внутри лежит именно она, и работает по всей цепочке причин. Сравнение текстов — хрупкий путь: сообщение поменяют, и ветка тихо перестанет срабатывать.

3. #rs_error_libs3 / 5
   Почему для ошибок берут отдельный крейт, а не пишут impl Error руками?

   A)Ручные Display, Error и From — шаблонный код на каждый вариант

   B)Стандартная библиотека не даёт трейта для ошибок приложения

   C)Ручную реализацию Error компилятор считает устаревшей

   D)Без крейта оператор ? для своих ошибок не работает

   показать ответ и разбор

   +A)Ручные Display, Error и From — шаблонный код на каждый вариант

   // разбор: Руками всё пишется и работает — просто на каждый вариант нужен рукав в Display, реализация From для источника и метод source. На десятке вариантов это страницы однообразного кода, который легко рассинхронизировать. Макрос убирает рутину, семантика остаётся ровно та же.

4. #rs_error_libs4 / 5
   Сервис отдаёт клиенту HTTP-статусы. Где мапить свою ошибку в код ответа?

   A)В самом enum ошибок: пусть каждый вариант хранит свой статус

   B)В обработчике каждого запроса вручную, ветками по варианту

   C)На границе транспорта: домен не знает про HTTP

   D)В middleware по тексту сообщения об ошибке

   показать ответ и разбор

   +C)На границе транспорта: домен не знает про HTTP

   // разбор: Домен формулирует, что произошло (NotFound, Conflict, Invalid), транспортный слой решает, как это выглядит снаружи — в веб-фреймворках это реализация IntoResponse или From для типа ответа. Так одна и та же ошибка обслуживает и HTTP, и очередь, и CLI, а смена протокола не расползается по бизнес-логике.

5. #rs_error_libs5 / 5
   Что означает #[error(transparent)] у варианта в thiserror?

   A)Вариант не попадает в публичную документацию типа ошибки

   B)Display и source делегируются вложенной ошибке без добавления своего текста

   C)Вариант сериализуется в JSON как обычная строка, без имени варианта и вложенных полей

   D)Вариант помечается устаревшим и вызывает предупреждение при использовании

   показать ответ и разбор

   +B)Display и source делегируются вложенной ошибке без добавления своего текста

   // разбор: Прозрачный вариант — это чистая обёртка: свой текст он не добавляет, а Display и source берёт у вложенной ошибки. Нужно это, когда ваш тип просто пробрасывает чужую ошибку наверх и добавить к ней нечего — иначе в логе появится бессмысленный повтор вроде «ошибка сервиса: ошибка базы: соединение закрыто». Для вариантов, где контекст есть, пишут обычную строку формата.