Matt Godbolt sold me on Rust by showing me C++

(www.collabora.com)

Show context

dvratil ◴[06 May 25 18:20 UTC] No.43908097[source]▶

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking reference to std::error_code to set an error (and having an overload with the same name that throws an exception on error if you forget to pass the std::error_code)...I understand there's 30 years of history, but it still is annoying, that even the standard library is not consistent (or striving for consistency).

Then you top it on with `?` shortcut and the functional interface of Result and suddenly error handling becomes fun and easy to deal with, rather than just "return false" with a "TODO: figure out error handling".

replies(24): >>43908133 #>>43908158 #>>43908212 #>>43908219 #>>43908294 #>>43908381 #>>43908419 #>>43908540 #>>43908623 #>>43908682 #>>43908981 #>>43909007 #>>43909117 #>>43909521 #>>43910388 #>>43912855 #>>43912904 #>>43913484 #>>43913794 #>>43914062 #>>43914514 #>>43917029 #>>43922951 #>>43924618 #

1. dabinat ◴[06 May 25 18:51 UTC] No.43908419[source]▶

>>43908097 #

I wish Option and Result weren’t exclusive. Sometimes a method can return an error, no result or a valid result. Some crates return an error for “no result”, which feels wrong to me. My solution is to wrap Result<Option>, but it still feels clunky.

I could of course create my own type for this, but then it won’t work with the ? operator.

replies(6): >>43908475 #>>43908590 #>>43908603 #>>43909135 #>>43916870 #>>43928540 #

2. vjerancrnjak ◴[06 May 25 18:56 UTC] No.43908475[source]▶

>>43908419 (TP) #

This sounds valid. Lookup in a db can be something or nothing or error.

Just need a function that allows lifting option to result.

3. dicytea ◴[06 May 25 19:09 UTC] No.43908590[source]▶

>>43908419 (TP) #

> I could of course create my own type for this, but then it won’t work with the ? operator.

This is what the Try[^1] trait is aiming to solve, but it's not stabilized yet.

[^1]: https://rust-lang.github.io/rfcs/3058-try-trait-v2.html

4. atoav ◴[06 May 25 19:11 UTC] No.43908603[source]▶

>>43908419 (TP) #

I think Result<Option> is the way to go. It describes precisely that: was it Ok? if yes, was there a value?

I could imagine situations where an empty return value would constitute an Error, but in 99% of cases returning None would be better.

Result<Option> may feel clunky, but if I can give one recommendation when it comes to Rust, is that you should not value your own code-aesthetical feelings too much as it will lead to a lot of pain in many cases — work with the grain of the language not against it even if the result does not satisfy you. In this case I'd highly recommend just using Result<Option> and stop worrying about it.

You being able to compose/nest those base types and unwraping or matching them in different sections of your code is a strength not a weakness.

5. Arnavion ◴[06 May 25 20:11 UTC] No.43909135[source]▶

>>43908419 (TP) #

Result<Option> is the correct way to represent this, and if you need further convincing, libstd uses it for the same reason: https://doc.rust-lang.org/stable/std/primitive.slice.html?se...

6. estebank ◴[07 May 25 15:19 UTC] No.43916870[source]▶

>>43908419 (TP) #

For things like this I find that ? still works well enough, but I tend to write code like

    match x(y) {
        Ok(None) => "not found".into(),
        Ok(Some(x)) => x,
        Err(e) => handle_error(e),
    }

Because of pattern matching, I often also have one arm for specific errors to handle them specifically in the same way as the ok branches above.

7. 0x457 ◴[08 May 25 17:16 UTC] No.43928540[source]▶

>>43908419 (TP) #

Well, I think returning "not found" when action performed was an "update X" and X doesn't exist. Result<Option> is totally normal where it makes sense, tho.

↑