Comment by GoblinSlayer
3 hours ago
Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result<Option<T>>? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result<Option<T>> from an average function call?
>> Also why Result<Option<T>>? Isn't Result already Option by itself?
No. I've written code that returns Result<Option<T>>. It was a wrapper for a server's query web API.
The Result part determines whether the request succeeded and the response is valid.
The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Session ID does not exist, then the Rust wrapper could return OK(None) meaning that the request succeeded, but that no such session was found.
If I ask my repository (backed by an sql db) to get a user, there might be 3 different scenarios I'm interested in:
- Technical problem (like connection problems) means I don't know what's in the db
- No technical problem, but no user entry
- No technical problem, and a user entry
You need the Result for the technical problems, and the Option for whether there's a user entry or not.