🦀 Error Handling: Библиотеки против Приложений
Часто вижу в код-ревью кашу из способов обработки ошибок. Давайте раз и навсегда зафиксируем базу, чтобы ваш код был идиоматичным.
Есть два лагеря, и вам нужно быть в обоих, но в разное время:
1. Вы пишите Библиотеку?
Используйте
Почему: Вашим пользователям важно
2. Вы пишите Приложение (CLI, Backend)?
Используйте
Почему: Вам чаще всего плевать на тип ошибки в глубине стека, вам важно прокинуть её наверх (
Итог: В библиотеках даем структуру (
#rust #tips #error_handling
👉 @rust_lib
Часто вижу в код-ревью кашу из способов обработки ошибок. Давайте раз и навсегда зафиксируем базу, чтобы ваш код был идиоматичным.
Есть два лагеря, и вам нужно быть в обоих, но в разное время:
1. Вы пишите Библиотеку?
Используйте
thiserror.Почему: Вашим пользователям важно
матчить ошибки. Им нужно знать, что именно пошло не так (NetworkError, ParseError), чтобы программно на это отреагировать. Вы не должны навязывать им тяжелые трейты.
#[derive(thiserror::Error, Debug)]
pub enum MyLibError {
#[error("IO error: {0}")]
Io(#[from] std::io::Error),
#[error("Invalid header")]
InvalidHeader,
}
2. Вы пишите Приложение (CLI, Backend)?
Используйте
anyhow.Почему: Вам чаще всего плевать на тип ошибки в глубине стека, вам важно прокинуть её наверх (
main), залоггировать контекст и упасть (или отдать 500-ку).
use anyhow::{Context, Result};
fn main() -> Result<()> {
let config = std::fs::read_to_string("config.toml")
.context("Не удалось прочитать конфиг")?;
Ok(())
}
Итог: В библиотеках даем структуру (
thiserror), в приложениях собираем контекст (anyhow). Не смешивайте.#rust #tips #error_handling
👉 @rust_lib
👍22👎1🥰1💩1