SOF: Is this being the error usage still acceptable?

Recommends Err("something")? instead of the return, which I interpret as using the erroring from badly called Err to generate an Error object to be used in Box. Kind of a Rocky Horror solution (don't dream the error, be the error) it seems. It is concise. Is it considered a good way to do it?

Personally, I don't like it. Err("something")? to me reads the same as match Some("something") { ... }; a misuse of the feature. I would just write return Err("something".into());.

That said, I don't believe there's even an optional clippy lint for it let alone an on-by-default one, so I don't think it can be said that it's "bad style". Just up to your own preference.

5 Likes

Another thing which can matter is that (at least at the time I looked at it) the compiler wasn't able to deduce that Err("something")? won't fall through to the parent block in the cases like originally asked, if we add a move to the inner block such as if condition { move(something); Err("something")? } something.foo(); whereas making it explicit via return Err("something".into()) the compiler is well aware that it can never fall through.

So I think what Heliozoa recommends is accepted in more situations too, perhaps the compiler either (could, or has) learned of this, but I feel it's worth being more explicit.

1 Like

But you can do

    return Err("something")?;

right?

Then compiler would understand everything.

2 Likes

I didn't expect it to, except in the weird Result<Result<T, T>, T> case(or something) where the Ok has the right type?

But surprising to me at least with some simple examples it does seem to work...
Edit: So I suppose it is actually deducing that Err("something")?, implies Result<!, Box<dyn Error>>, but without the return fails to deduce that that implies an implicit return.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.