Unwrap means it forces to evaluate the result as an ”ok value”. If it’s an ”error value”, it will crash. It’s a bad practice to rely on it, as it’s one of the most common ways a Rust programs can crash.
Rust offers many options to handle errors that don’t risk crashing. For example, unwrap_or_default, which means ”if it’s an error value, use the default value for this type, such as 0 for integers”
A very typical use-case would be getting something from a HashMap (or a Vector) and calling unwrap because you know it must exist (as you got a reference to the index or object that must be valid in the HashMap or Vector).
Or if you call a function that returns Option<…> depending on the current state and you know that it must return Some(…) in the current situation.
Languages like Java or C++ have Exceptions, which are errors, that are not explicitly mentioned in the function signature. Meaning, you might need to handle an exception you didn’t even know existed. And if you don’t, your program will just crash when these exceptions occur.
In Rust all errors are explicitly mentioned and part of the return type.
Because of this Rust has a lot of ways to quickly handle an error. One of those ways is “Trust me, bro” (or .unwrap()), which converts the combined error/success return type into just a success type, causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
Crashing through unwrap is not necessarily restoring unsafe behavior of other languages though. I’d consider this wayyyy better than silently continuing with invalid value until the program tries something that doesn’t make sense/is overreaching and it crashes.
Sad to be the one that does not get it.
Unwrap means it forces to evaluate the result as an ”ok value”. If it’s an ”error value”, it will crash. It’s a bad practice to rely on it, as it’s one of the most common ways a Rust programs can crash.
Rust offers many options to handle errors that don’t risk crashing. For example, unwrap_or_default, which means ”if it’s an error value, use the default value for this type, such as 0 for integers”
I mean using unwrap is not bad practice if the value is guaranteed to not be none, which can happen frequently in some applications.
If it’s guaranteed to not be
None, why is it anOption?Here’s a bad example but hopefully captures the why. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=43d055381e7bb52569c339d4526818f4
We have a condition we know must be satisfied (the option will always be Some), but cant prove in code.
Oh, it can happen when you do calculations with compile-time constants…
But the GP’s claim that it’s a “frequent” thing is suspect.
(Crashing is also useful when you are writing and-user applications, but you’ll probably want .expect like in the meme.)
A very typical use-case would be getting something from a HashMap (or a Vector) and calling unwrap because you know it must exist (as you got a reference to the index or object that must be valid in the HashMap or Vector).
Or if you call a function that returns
Option<…>depending on the current state and you know that it must returnSome(…)in the current situation.A good example would be regex. After validating it when writing the program it should always compile, although this could also be solved with a proc macro that validates the regex at compile time.
Unwrap is good for prototyping and trying out stuff fast, but it generally shouldn’t make it past a code review onto main, unless you’re very sure
Exactly.
Personally, I call it “python mode” since you’re staying on the “happy path” and let the program just crash out if those expectations aren’t met.
Thanks.
Languages like Java or C++ have Exceptions, which are errors, that are not explicitly mentioned in the function signature. Meaning, you might need to handle an exception you didn’t even know existed. And if you don’t, your program will just crash when these exceptions occur.
In Rust all errors are explicitly mentioned and part of the return type. Because of this Rust has a lot of ways to quickly handle an error. One of those ways is “Trust me, bro” (or .unwrap()), which converts the combined error/success return type into just a success type, causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
Crashing through unwrap is not necessarily restoring unsafe behavior of other languages though. I’d consider this wayyyy better than silently continuing with invalid value until the program tries something that doesn’t make sense/is overreaching and it crashes.
every 20 lines… haha that’s so much… visibly sweating