It’s a little verbose (like most of Rust), but I really like this approach. It’ll make a lot of logic easier to reason about. I missed that in the article, so thanks for pointing it out.
It’s not a secret approach or anything. thiserror gives you that with a simple #[from] attribute annotation on the relevant error variant on your Error enum (which is what your Error type should be).
In your case, this just works because you’re not attaching custom context to your error. Usually, you would want to attach some context, and in that case, .map_err()would obviously still be needed, and that’s fine. This idea of having to write as little code as possible is stupid.
Sometimes, attaching context once is sufficient, sometimes it’s not. If it’s the former, then you can still do From in your bigger error enums which have variants from your smaller error enums (e.g. crate-level Error type with variants trivially wrapping module-level Error types).
This idea of having to write as little code as possible is stupid.
Is it? Not only is it less work, but generally makes the code way easier to reason about. In this case, instead of just seeing simple function calls explaining the logic flow, you visually have to parse all this weird extra cruft that is generally irrelevant to what the block is doing.
It’s a little verbose (like most of Rust), but I really like this approach. It’ll make a lot of logic easier to reason about. I missed that in the article, so thanks for pointing it out.
(Didn’t read the article.)
It’s not a secret approach or anything.
thiserrorgives you that with a simple#[from]attribute annotation on the relevant error variant on yourErrorenum (which is what yourErrortype should be).In your case, this just works because you’re not attaching custom context to your error. Usually, you would want to attach some context, and in that case,
.map_err()would obviously still be needed, and that’s fine. This idea of having to write as little code as possible is stupid.Sometimes, attaching context once is sufficient, sometimes it’s not. If it’s the former, then you can still do
Fromin your bigger error enums which have variants from your smaller error enums (e.g. crate-levelErrortype with variants trivially wrapping module-levelErrortypes).Is it? Not only is it less work, but generally makes the code way easier to reason about. In this case, instead of just seeing simple function calls explaining the logic flow, you visually have to parse all this weird extra cruft that is generally irrelevant to what the block is doing.