[svnpenn]

> If a library panics on invalid user data, that's a pretty serious bug.

I swear, sometimes it seems like Rust people are from another planet. What do you think "unwrap" does? It's not used in every library, but certainly in many of them.

[nindalf]

> seems like Rust people are from another planet.

There’s no need to talk in a condescending manner.

What they said was correct - an “unwrap” outside of test/prototyping is considered a serious bug. They Rust loving strawmen you’re creating never claimed that every line of Rust ever written is perfect and bug free.

[Nathanba]

So you essentially want me to write error handling code nonstop, constantly, all across my functions. Practically after every 5 lines of code there is going to be an unwrap() where I'm not allowed to call unwrap() so I have to know the details of the implementation, the error code, deal with the error code, return early from the function and then gracefully handle it all. Meanwhile in a language that has exceptions I just put a try catch around all the code I think works fine but maybe not and I deal with it in a single location in a way where I dont have to care about what the precise error code might be. Error code programming really seems to be objectively worse for everyone except the compiler writer. Somehow people let themselves get convinced that this is better when it's objectively not.

[tinco]

Rust has syntactic sugar to help you coalesce error handling into returning a single Result. You'd have to check and make sure the library you use doesn't call unwrap willy nilly. As crazy as that sounds it is actually common practice in the Rust community, there's tools that reveal use of unwrap and unsafe in your dependencies.

In the end you don't use Rust because it's so easy and nice to use (unless you come from C/C++). You come to Rust because you want meticulous control over performance, and you don't want to sacrifice safety to attain that.

If that's not why you're using it, I agree you're probably better off choosing Java, it's plenty fast and comfortable to use, especially if you pick modern tooling.

[Hackbraten]

> You'd have to check and make sure the library you use doesn't call unwrap willy nilly.

That statement really resonates with me. If you use a library, you’re responsible for what it does, just like how you’re responsible for your own code.

[nindalf]

?

Are you mistaking Rust for some other language? Error handling in Rust is mostly just using the `?` operator.

The Rust book explains - https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

[kaba0]

That’s what the ? syntactic sugar is meant to solve. It will return at the point with an Option null, or the error variant of Result if the preceding expression’s error can be converted to it.

something.map_err(…)? is quite readable in my opinion and that is the worst case, when your method returns a Result<..,..> but the called method has an Optional return type. Otherwise it is just a single ?.

Sure, I do believe that exceptions are superior but we do have to understand that rust is a low-level language, period. It is very expressive considering its nature, but it will never be as productive as a managed language in my opinion - we have this distinction for a very good reason. If you want maximal control over what happens “behind the scenes” you loose some automatism that could improve productivity.

[allisdust]

How is try catch any better than Err/Ok pattern? Code that doesn't handle error cases shouldn't even pass any code reviews. This is exactly why Rust guides the programmers in a certain paths to ensure all cases are always handled. If you really don't want check the Err/Ok in each call, you are free to use '?' to pass that burden to higher functions.

[nindalf]

They didn’t know about `?`. My guess is that they read the first page about error handling, where it talks about unwrap and match. They didn’t get to the second page, where `?` is introduced.

Remarkable that people with such little knowledge feel comfortable talking so much.

[atoav]

No, you should not unwrap unless you know it is safe to do so. You should also add a comment why it is safe to unwrap, if it is not obvious.

Many programmers are writing code for sunny weather only, with error handling being something you might add as an afterthought if your code starts to feel a little too brittle.

In my eyes error handling is just as important to do correctly as getting the core of the functionality done, because error handling is a core functionality of any program, especially if we speak of libraries others are meant to use.

Error handling is what differenciates engineering from coding.

[Gwypaas]

Or simply use Thiserror together with bubbling.

https://crates.io/crates/thiserror/1.0.24

[svnpenn]

Sorry, but if the language cant even get errors right, I'm certainly not going to download a package to do it.

[orf]

It’s definitely pretty good once you’ve used it.

[singularity2001]

What OP meant is that proponents of Rust are often a bit out of touch with reality: Go to github and find a random Rust repo which doesn't use unwrap excessively. And is thus full of serious bugs, according to your wording.

[nindalf]

> Go to github and find one Rust repo which doesn't use unwrap excessively.

Consider serde-json, a widely used library to serialise and deserialise json. You asked me to find “one Rust repo”. Ok here it is - https://github.com/serde-rs/json/search?q=unwrap&type=. Of the 22 uses of unwrap, nearly all are in test code or in comments. Of the remaining 3 or 4, they seem safe to me. But maybe they’re not. Could you think of some json input that could trigger a panic from one of those unwraps?

I’ll put my money where my mouth is. I’ll donate $100 to a charity of your choice if you can find that.

But if you can’t, at least have the honesty to admit that you misspoke when you said not even a single repo without “excessive” use of unwraps exists.

[pkolaczk]

Not every use of unwrap is a bug. For example a regex library returns Result on regex construction because the passed regex could be invalid. But if you construct the regex yourself, from a hard coded string, you know it is correct. Then you just use unwrap and it is ok.

[pjlegato]

People don't write bugs on purpose. That hardcoded string that you know is correct is sometimes not actually correct.

[Georgelemental]

And crashing early is often the best solution in that case.

[nulld3v]

The assertion remains true though. Unwrap should only be used if you are prototyping or you are 100% sure it will never actually panic.

It's just like the IndexOutOfBounds exception in Java. Many functions can theoretically throw it, but most libraries and programs do not catch it because usually if it is thrown it means that something happened that the programmer did not expect and therefore the program should crash.

[elbear]

There's a difference between what you should do and what people actually do. If a lot of them use unwrap in production, then OP's argument is valid.

[nulld3v]

The problem would not be that it is commonly used, the problem would be that it is abused. And I don't see that happening currently.

The assertion that "If a library panics on user data, that's a pretty serious bug" remains true.

If a library is panicking on invalid user data, it is because they are abusing panic, which is a serious bug. Or they just didn't realize that their code could panic, which is also a serious bug.

[justinpombrio]

> What do you think "unwrap" does?

It panics just like my `my_vector[2]` example does. What did you think `my_vector[2]` did? Libraries use `my_vector[2]` too. I don't get why we're changing topics from one commonly used panicking operation to another.

[varajelle]

Unwrap is supposed to be used when the developer know that the error can't happen. Or that if that error happen there is no recovery anyway, and the best thing to do is to abort the program.