Slapping on a `.expect` is also error handling!
-
wrote on last edited by [email protected]
Don't say anyway, say anyhow
-
Don't say anyway, say anyhow
-
Sad to be the one that does not get it.
-
Don't say anyway, say anyhow
I prefer it over alternatives:
- Exceptions: ”Oh no! Guess I’ll just die”
- Error codes: ”If a non-zero error code is returned but no one notices, is it really an error?”
-
Don't say anyway, say anyhow
Elixir {:error, IDK lol}
-
every 20 lines.. haha that's so much.. visibly sweating
-
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”
-
Sad to be the one that does not get it.
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. -
I mean using unwrap is not bad practice if the value is guaranteed to not be none, which can happen frequently in some applications.
-
I mean using unwrap is not bad practice if the value is guaranteed to not be none, which can happen frequently in some applications.
wrote on last edited by [email protected]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.
-
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.causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
Wellllll it's more of an abrupt exit rather than a crash, which is still better than eg. silently accessing beyond the end of an array, or ending up with a pointer to nowhere when you thought you had a sane memory reference.
-
Don't say anyway, say anyhow
try { execute.SomeMethod(); } catch(Exception ex) {} -
wrote on last edited by [email protected]
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
-
causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
Wellllll it's more of an abrupt exit rather than a crash, which is still better than eg. silently accessing beyond the end of an array, or ending up with a pointer to nowhere when you thought you had a sane memory reference.
“An abrupt exit”, more commonly known as a “crash”.
If you’re going to argue that an exit through
panic!()is not a crash, I will argue that your definition of a crash is just an abrupt exit initiated by the OS. In other words, there’s no meaningful distinction as the result is the same. -
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.
-
“An abrupt exit”, more commonly known as a “crash”.
If you’re going to argue that an exit through
panic!()is not a crash, I will argue that your definition of a crash is just an abrupt exit initiated by the OS. In other words, there’s no meaningful distinction as the result is the same.wrote on last edited by [email protected]I don't think that's a valid comparison. The behavior does differ when it comes to cleanly releasing resources. Rust's panic performs the drop actions for the current values on the stack, a SIGILL or SIGSEGV crash doesn't.
#[derive(Debug)] struct MyStruct {} impl Drop for MyStruct { fn drop(&mut self) { println!("{:?}", "imagine cleanup here"); // this is called } } fn main() { let a = MyStruct {}; panic!("panic!"); println!("{a:?}"); } -
I don't think that's a valid comparison. The behavior does differ when it comes to cleanly releasing resources. Rust's panic performs the drop actions for the current values on the stack, a SIGILL or SIGSEGV crash doesn't.
#[derive(Debug)] struct MyStruct {} impl Drop for MyStruct { fn drop(&mut self) { println!("{:?}", "imagine cleanup here"); // this is called } } fn main() { let a = MyStruct {}; panic!("panic!"); println!("{a:?}"); }That’s fair, although technically you could catch SIGSEGV and release resources that way too.
Also, given that resources will be reclaimed by the OS regardless of which kind of crash we’re talking about, the effective difference is usually (but not always) negligible.
Either way, no user would consider a
panic!()to be not a crash because destructors ran. And most developers don’t either. -
I prefer it over alternatives:
- Exceptions: ”Oh no! Guess I’ll just die”
- Error codes: ”If a non-zero error code is returned but no one notices, is it really an error?”
The crash early, crash often approach of Erlang has made for some amazingly resilient systems.
One time on a project I was working on, some horribly broken code was merged (nobody in the team had even heard of reviewing code). As soon as a specific call was made, it was executed once and then the thread crashed. The only way we noticed was that response times increased with load. All data and behavior was still correct. Whole nodes could go down and all you notice is a dip in performance until it comes back online.
Of course it requires special care in designing. Everything runs in stateless server threads with supervisors restarting them as needed. This in turn requires some language support, like lightweight threads. Our application would happily run tens of thousands of threads on an ancient sparkstation.
-
try { execute.SomeMethod(); } catch(Exception ex) {}wrote on last edited by [email protected]goto fail; -
I mean using unwrap is not bad practice if the value is guaranteed to not be none, which can happen frequently in some applications.
wrote last edited by [email protected]If it's guaranteed to not be
None, why is it anOption?
