4 ms·
The "status quo" way erodes the benefit of Rust's error system. The whole point (in my mind at least) of type safe errors is to know in advance all if the fail
by resonious 1y ago
The "status quo" way erodes the benefit of Rust's error system.
The whole point (in my mind at least) of type safe errors is to know in advance all if the failure modes of a function. If you share an error enum across many functions, it no longer serves that purpose, as you have errors that exist in the type but are never returned by the function.
It would be nice if the syntax made it easier though. It's cumbersome to create new enums and implement Error for each of them.
- klodolph 1y agoIt’s not just syntax, there are semantic problems. Like, function 1 fails for reason A or B. Function 2 fails for A or C. You call both functions. How do you pattern match on reason A, in the result of your function? In Go, there’s a somewhat simple pattern for this, which is errors.Is().
- Expurple 1y agoIt's a tradeoff. When you have a "flat" union like `A | B | C` that makes it easy to pattern-match "leaf" errors, you give up the ability to add any additional context in function1 and function2. Although, there are workarounds like struct Error { leaf_error: A | B | C, context: Vec<String>, }