4 ms·
My initial reaction was similar, and I totally agree that there's a lot of essential complexity in this area. At the same time, there might be room for an ergo
by bacon_waffle 4y ago
My initial reaction was similar, and I totally agree that there's a lot of essential complexity in this area. At the same time, there might be room for an ergonomic improvement too. It seems like the `?` operator is maybe a little bit too nice - I find that, in practice, the step up in effort between:
let x = some_function()?;
versus
let x = match some_function() {
Ok(value) => value,
Err(Error::ThatOneRetryableError) => {
// Retry
}
err => return err
};
...sometimes is just a little bit too much to bother. Is there a pattern/macro/??? that makes this sort of thing a little nicer?
- tempodox 4y agoThere are no one-size-fits-all abstractions for these things. Where to handle an error and deciding what to do under which circumstances is uncomfortable detail work. But it needs to be done if you want reliable software.
- bacon_waffle 4y agoIf it's fair to say that the abstraction we're talking about is a semantic thing, rather than a syntactical thing, then I think we're in total agreement. Rust (as far as I know - I'm totally not an expert, nor a programming language person) makes handling the black-and-white cases really nice, but it would be nice if there were less friction for handling the in-between cases. I'm not sold on the solution requiring a 3-enum `Outcome` vs a 2-enum `Result`, but also feel that things could be better.