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.
Yes, code golf practiced for any reason other than the sheer joy of it is “stupid.” It especially doesn’t belong in production code. If typing is really so bad, there are any number of local agents that are competent to finish that map fragment for you.
(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.
Yes, code golf practiced for any reason other than the sheer joy of it is “stupid.” It especially doesn’t belong in production code. If typing is really so bad, there are any number of local agents that are competent to finish that map fragment for you.
It’s not about “sheer joy”, nor obfuscation. It’s about making code easier to write and easier to grok.