Um, it’s pretty obvious why Result<Option<Result<Option<T>>>> or Result<(),()> is bad, I’m not going to spend time explaining when I doubt you’re asking in good faith.
Of course I’m asking in good faith. I wouldn’t have asked how you’d implement the same problem yourself if I wasn’t interested.
But you also have to understand that it’s very easy for people to say “x is bad” when actual real world problems sometimes require a small smattering of ugly code. So it’s not unreasonable for me (or anyone else) to ask how you’d write a solution to the same problem.
Now what I’m trying to understand is whether the examples highlighted by the author as ugly, was ugly because it’s bad code. Or ugly because it was the right solution which lead to ugly code. Which is why I was asking for your preferred solution.
Looking at the code briefly, the first example could be written as
let msg = timeout(Duration::from_secs(2), receiver.next()).await.ok()??;
// not shown in article, but next line of code
let Message::Text(frame) = msg_result.ok()? else {
return None;
};
Looks like the fixed the second issue with anyhow::Result<()>
But you also have to understand that it’s very easy for people to say “x is bad” when actual real world problems sometimes require a small smattering of ugly code. So it’s not unreasonable for me (or anyone else) to ask how you’d write a solution to the same problem.
Now what I’m trying to understand is whether the examples highlighted by the author as ugly, was ugly because it’s bad code. Or ugly because it was the right solution which lead to ugly code. Which is why I was asking for your preferred solution.