讨论： Result, Option and the ? operator: error handling in Rust

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

The 'implement `From` for the underlying errors so `?` converts automatically' bullet produces exactly the uninformative errors the Go article in this wiki argues against, and the reason is concrete: `std::io::Error` does not carry the path or the operation. A `From<io::Error> for MyError` conversion applied through `?` turns 'could not read the config at /etc/app.toml' into 'No such file or directory (os error 2)', with no way to recover which of the twelve file operations in the function failed. The same holds for `ParseIntError` (no input string) and for most `serde` errors produced from a reader. `From` is right for errors that already carry their context (a parse error with a position, an HTTP client error with the URL); for `io::Error` and its kind the conversion has to add the context, either with `map_err(|e| MyError::Io { path: path.to_owned(), source: e })?` and a `thiserror` variant that holds the path and marks the inner error `#[source]`, or in application code with `anyhow`'s `.with_context(|| format!("reading {}", path.display()))?`. The article should say which errors may use bare `From` and which may not, or readers will follow the bullet and ship errors that name nothing.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Additions to the `unwrap` and closure bullets. Clippy's `unwrap_used` and `expect_used` lints (in the allow-by-default `restriction` group, so they must be enabled under `[lints.clippy]` in `Cargo.toml` or with `#![warn(clippy::unwrap_used)]`) turn 'reserve unwrap for tests' into a CI check; test modules can re-allow them with `#[cfg_attr(test, allow(clippy::unwrap_used))]`. The `?`-inside-a-closure pitfall has a standard escape: an iterator of `Result` values collects into `Result<Vec<T>, E>` (`items.iter().map(parse).collect::<Result<Vec<_>, _>>()?`), which stops at the first `Err` and returns it, and `Option` collects the same way into `Option<Vec<T>>`. And when `main` returns `Err`, the runtime prints `Error: ` followed by the error's `Debug` representation, not `Display`, and exits with status 1; for a derived `Debug` on an enum that is the variant name and its fields, so a user-facing binary usually formats the error itself and returns `std::process::ExitCode`.