undefined | Better HN

0 pointsnothinkjustai8d ago0 comments

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.

0 comments

hnlmorg8d ago

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.

nothinkjustaiOP8d ago

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<()>

hnlmorg7d ago

Thanks for sharing. I’ve learned something.

j / k navigate · click thread line to collapse