|
|
|
|
|
by Fellshard
2028 days ago
|
|
I think I see what you're getting at, but let me point out why I still think it does something more than what Java exceptions allow: let x = doRiskyThing();
match x { // Pattern match on x
Ok(y) => y.doThing(), // Giving the result a different name clarifies what's happening
Err(e) => ...
}
x.unwrap().doThing(); // You can assume it's Ok, but you explicitly risk the application panicking
Of note, Result::unwrap is approximately the following: match x {
Ok(y) => y
Err(_) => panic!()
}
x is still a valid value for the duration, and is never uninitialized; and whether you handle each case in a match or unwrap, both success and failure are considered and responded to before moving on. The Java checked exception code does that as well, except that it is unclear whether `doRiskyThing()` is throwing the exception, or `x.doThing()`; it's hard to reason about where the error originates from, and how much work was partially completed. In Java, the best way to circumvent this is - if possible - to keep try-clauses as tight as possible. |
|