| ▲ | Rohansi 2 hours ago |
| > when you do unwrap() you're saying the Result should NEVER fail Returning a Result by definition means the method can fail. |
|
| ▲ | Buttons840 42 minutes ago | parent | next [-] |
| Division can fail, but I can write a program where I'm sure division will not fail. |
|
| ▲ | SchwKatze 2 hours ago | parent | prev | next [-] |
| Yeah, I think I expressed wrongly here. A more correct version would be: "when you do unwrap() you're saying that an error on this particular path shouldn't be recoverable and we should fail-safe." |
|
| ▲ | Dylan16807 2 hours ago | parent | prev [-] |
| > Returning a Result by definition means the method can fail. No more than returning an int by definition means the method can return -2. |
| |
| ▲ | yoyohello13 2 hours ago | parent [-] | | What? Results have a limited number of possible error states that are well defined. | | |
| ▲ | Dylan16807 2 hours ago | parent [-] | | Some call points to a function that returns a Result will never return an Error. Some call points to a function that returns an int will never return -2. Sometimes you know things the type system does not know. | | |
| ▲ | Rohansi 2 hours ago | parent [-] | | The difference is functions which return Result have explicitly chosen to return a Result because they can fail. Sure, it might not fail in the current implementation and/or configuration, but that could change later and you might not know until it causes problems. The type system is there to help you - why ignore it? | | |
| ▲ | Dylan16807 2 hours ago | parent [-] | | Because it would be a huge hassle to go into that library and write an alternate version that doesn't return a Result. So you're stuck with the type system being wrong in some way. You can add error-handling code upfront but it will be dead code at that point in time, which is also not good. |
|
|
|
|
