3 ms·
> And at the end of the day, it turns out forced error checking is an idea everyone keeps reinventing, because it is actually useful to know what errors can be
by masklinn 3y ago
> And at the end of the day, it turns out forced error checking is an idea everyone keeps reinventing, because it is actually useful to know what errors can be "thrown".
The problem of java's checked exceptions is not that being explicit is bad, it's that java's implementation is terrible.
- pjmlp 3y agoMore like, most people rather complain than learn how to use them properly.
- LelouBil 3y agoYeah, exceptions and try/catch blocks have way worse ergonomics that Result<Err,Ok>.
- pjmlp 3y agoThen why does Rust need third party crates for sane ergonomics?
- LelouBil 3y agoI'm not really talking about the "errors" ergonomics, but more about error handling. The methods like .map .map_err .and_then I feel are way easier to reason about and also often shorter that what would happen in a control flow breaking catch block.
- veber-alex 3y agoBecause there isn't a one size fits all solution to error handling? Because before anyhow/thiserror became popular there were 5 other popular crates for handling errors and if Rust added one of those to std we would be stuck with a subpar solution forever? Because cargo is so easy to use that your preferred error handling solution is one `cargo add` command away? Because for simple cases the tools the standard library offers are good enough?
- pjmlp 3y agoOr maybe, because the feature wasn't properly developed, and needs community fixes to make it usable.