🦀✨ Новый взгляд на обработку ошибок в Rust: пора отказаться от гигантских enum?

Ferris-краб жонглирует множеством разноцветных блоков «Error», показывая, как в Rust можно грамотно разделять разные типы ошибок вместо единого грубого enum.

Каждый программист, работавший с Rust, знает его великолепную систему типов и возможности по обработке ошибок через типы данных Result. Однако, несмотря на всю красоту языка, в Rust укоренился один спорный подход — огромные перечисления (enum), включающие все возможные ошибки, которые могут произойти в рамках целого модуля или даже крейта. В свежей статье Феликса Кнорра представлен альтернативный подход, предлагающий использовать небольшие и гибкие структуры для описания ошибок. Давайте разберёмся, что в этом подходе интересного и полезного.

🔍 Что не так с привычными гигантскими enum?

Типичная ситуация в Rust-проектах выглядит примерно так:

enum HugeErrorEnum {
Io(std::io::Error),
ParseError(ParseError),
Network(NetworkError),
Custom(String),
}

Такие большие enum ведут к нескольким проблемам:

• ❌ Нечитаемость: часто возникает путаница, какие именно ошибки конкретная функция может вернуть.
• 🐛 Ошибки при поддержке: при изменении или добавлении нового варианта ошибки приходится править огромное количество кода.
• 📖 Необходимость постоянного обращения к документации, чтобы понять, какие именно ошибки актуальны для текущего контекста.

🚧 Предлагаемое решение: мелкие структуры вместо больших enum

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

Пример простого подхода из популярного крейта terrors:

fn perform_action() -> Result<(), OneOf![NotFound, InvalidInput]> {
//...
}

Однако у такого подхода есть и минусы:

• ⚙️ Необходимость постоянного использования .map_err(OneOf::broaden) для конвертации.
• 📌 Слишком большая многословность в реальном коде с множеством ошибок.

🔥 Компромиссный вариант — crate error_set

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

Вот как выглядит использование error_set в реальном проекте автора:

error_set! {
BtlePlug = {
BtlePlug(btleplug::Error)
};

FindDeviceError = { NoAdapter, Timeout, DeviceNotFound } || BtlePlug;
ConnectionError = { NoRxChar, NoTxChar } || BtlePlug;
OperationError = FindDeviceError || ConnectionError || SendError(mpsc::SendError<Vec<u8>>);
}

Что здесь интересного?

• 🚀 Автоматическая конвертация ошибок с помощью оператора ?. Кратко, удобно и надёжно.
• 🧩 Гибкость в объединении наборов. Каждый набор ошибок может включать в себя другие наборы, что снижает дублирование кода.
• 📦 Читаемость и лёгкость поддержки. Гораздо проще понять, какие именно ошибки может вернуть конкретная функция.

Более того, этот подход упрощает рефакторинг: если добавляется новая ошибка, вам не нужно править весь код — достаточно просто дополнить соответствующий набор ошибок.

🤔 Другие интересные подходы

Автор также упоминает несколько других подходов, заслуживающих внимания:

• 📌 SmartErr – ещё один crate, предлагающий интересную реализацию обработки ошибок с минималистичным подходом.
• 🧙 Макросы атрибутов – гипотетический крейт, который автор однажды видел, позволял автоматически генерировать enum ошибок, анализируя тело функции (увы, ссылка была утеряна, но идея интригующая!).

💬 Личное мнение автора статьи

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

Особенно полезен такой подход при работе с библиотеками, API которых постоянно расширяется. Гибкие структуры ошибок позволяют делать изменения без боли, сохраняя совместимость и удобство использования.

📝 Выводы и рекомендации

Использование мелких структур и crate вроде error_set кажется отличным решением для масштабируемых проектов на Rust. Такой подход стоит внедрять постепенно, проверяя его эффективность в каждом конкретном случае. Главный принцип: чем конкретнее и меньше тип ошибки, тем проще с ней работать.

В конце концов, Rust известен своей строгой системой типов и удобством работы с ошибками — так почему бы не использовать эти преимущества по максимуму?

🔗 Полезные ссылки:

• 🦀 Оригинальная статья Феликса Кнорра
• 📦 Crate error_set на crates.io
• 📚 Crate terrors на crates.io