this post was submitted on 27 Sep 2023
190 points (97.5% liked)

Rust

6039 readers
16 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
190
The ???? operator (programming.dev)
submitted 1 year ago* (last edited 1 year ago) by snaggen to c/rust
 

I found this funny.

The context is as explained by @[email protected]

the issue is that you can't return from inside a closure, since the closure might be called later/elsewhere

and this post was the asnwer to the question by @[email protected]

you got me curious what the record for the longest ? operator chain on crates.io is

Original post: https://fosstodon.org/users/antonok/statuses/111134824451525448

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 16 points 1 year ago (3 children)

I'm writing my Rust wrong... I have match statements everywhere to the degree that it's cluttering up everything.

[–] aloso 7 points 1 year ago* (last edited 1 year ago) (1 children)

If all you do in the Err(e) => ... match arm is returning the error, then you absolutely should use the ? operator instead.

If the match arm also converts the error type into another error type, implement the From trait for the conversion, then you can use ? as well.

If you want to add more information to the error, you can use .map_err(...)?. Or, if you're using the anyhow crate, .with_context(...)?.

[–] [email protected] 3 points 1 year ago

You can also do map_err, which is a bit cleaner while keeping the mapping obvious. If you really need to do some logic on error, extracting that to the calling function is often better.

[–] BB_C 4 points 1 year ago

If the matches are causing too much nesting/rightward drift, then that could be an indicator that you're doing something wrong.

If it's the opposite, then you're probably doing something right, except maybe the code needs some refactoring if there is too much clutter.

If there isn't much difference, then it's a matter of style. I for example sometimes prefer to match on bools in some contexts because it makes things look clearer to me, despite it being not the recommended style. I'm also a proud occasional user of bool::then() and bool::then_some() 😉

Also, if you find yourself often wishing some API was available for types like bool, Option, and Result, then you don't have to wish for long. Just write some utility extension traits yourself! I for example have methods like bool::err_if(), bool::err_if_not(), Option::none_or_else(), and some more tailored to my needs methods, all available via extension traits.

Macros can also be very useful, although some people go for them too early. So if everything else fails to declutter your code, try writing a macro or two.

And it's worth remembering, there is no general rule, other than if the code is understandable for you and works, then you're probably okay irregardless of style. It's all sugar after all, unless you're really doing some glaringly wrong stuff.

[–] [email protected] 1 points 1 year ago

Most likely you can get by with adjusting the return type and using a ? or maping to a type that you can use the ? on.