No, you don't! When returning Result<T, E>, you can use ? on any Result<T2, E2> where E: From<E2>. In other words E doesn't have to be Box<dyn>, it just has to satisfy From<E2>.
Crates like thiserror make it easy to define your own error types that can be easily converted from all the other error types you can encounter in your functions! I do this whenever it doesn't make sense to use an inner error type directly, or whenever a function does its own validation that deserves its own error variant.
On top of that, I tend to also have error variants for each place in the function rather than only for each type of inner error. At error sites I do something like `.map_err(MyError::PlaceInTheFunction)?` rather than only `?`, and then errors become like a very efficient backtrace :)
[–] Graziano_M 2 days ago
[–] GreenDolphinSys 2 days ago
In other words implementing that trait lets you set a return type like Result<T, CustomAppError> use ? on it.
[–] LoganDark 2 days ago
[–] Graziano_M 2 days ago
> There's also Zig-style composable errors with yet another library.
[–] LoganDark 2 days ago
While I'd push back against implying From<E2> is part of the crate, thiserror is an idiomatic approach these days, so I can understand the confusion. I can totally see how they could come to favor Zig if this behavior is "the default", as opposed to Rust where you'd usually see it done with "yet another library".
And so I see "the author's point" has another meaning now: that Zig-style errors are good :)
Edit: oh, after looking into Zig-style errors more, this is actually not how they work! They don't nest, they just exist in a global namespace, so they don't come with any location data themselves, but you can compose sets of them. Less powerful, but certainly more appealing to some :) I think out-parameters can be used as a side channel for error context.
[–] Graziano_M 2 days ago
[–] GreenDolphinSys 2 days ago
[–] LoganDark 2 days ago
[–] tcfhgj 2 days ago