5 ms·

An important distinction is that rust doesn’t use exceptions for recoverable errors. You don’t have try/catch like you do in C++. Instead you use the Result typ

An important distinction is that rust doesn’t use exceptions for recoverable errors. You don’t have try/catch like you do in C++. Instead you use the Result type to propagate errors. This has the advantage of avoiding many of the downsides of exceptions (like leaving your program in a bad state) while making error handling more explicit.

Rusky 4y ago
This doesn't mean you don't still have to be panic-safe, though. This is mainly important for unsafe code, because it has to preserve memory safety even in the presence of panics. But it can also be important for safe code in an application that recovers from panics.
- celeritascelery 4y ago
  You are correct that there are circumstances where you have to consider panic safety. But those are rare. Most code is not unsafe, and catching panics is usually bad practice in Rust (though I am sure there are circumstances where it is needed). In C++ by contrast you have to think about panic safety almost everywhere. Rust’s error handling is a big improvement in that regard.
blub 4y ago
Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants their library to crash their program because someone was too lazy to propagate errors. Which brings me to the point: propagating errors is tedious enough that people are looking for shortcuts, which then cause other problems.
- spoiler 4y ago
  Somehow I must've been lucky enough to avoid this unwrap abuse in crates I use. I think you maybe meant converting between errors in Rust can be tedious sometimes, but propagation is pretty easy. The conversation is something that generally need's to happen rarely (like a few times per project?), but `thiserror` and `from` make this pretty ergonomic.
- burntsushi 4y ago
  For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is broken and thus leads to a panic. Nearly all code has runtime invariants in one form or another. The question is what happens when they're broken. In languages that are memory unsafe by default, the answer is often (but not always) "undefined behavior." In languages like Rust, or Python, or Go, the answer is often (but not always) "the process quits." The reality is more complicated than that, but those are a fine first approximation. For example, breaking a runtime invariant doesn't have to lead to undefined behavior or process termination. It can simply result in a logic error that leads to unexpected behavior. Of course, making the issue more complicated is that sometimes 'unwrap()' is abused. And indeed, sometimes it is used in cases where an error ought to be returned. I find this to be generally pretty rare in popular libraries. But the key point here is that you can't just say, "oh I see unwrap() in a library, so now I'm going to scream ABUSE!!!!" It's more complicated than that.
  - blub 4y ago
    How is it nonsense if you admit at the end (albeit after a straw-man of me allegedly screaming “abuse”) that it happens? Result is being sold on HN as a great solution to error handling while there’s several crates available which are needed to polish its rough edges, rough edges which have led to e.g. unwrap abuse in the past. It is tedious to shuffle around results, but this is never part of the sales pitch. And for those of us that don’t want to depend on all sorts of crates for the simplest things, that’s the reality. Re your reply “Maybe improve your reading comprehension. I said "(partial) nonsense." Therefore, some of what you said wasn't nonsense. But some is. What a fucking revelation.” Partial nonsense isn’t nonsense by definition, I believe, but I won’t dwell that point. I am surprised seeing a Rustacean being (mildly) offensive and even saying the f-word. I must say that I am proud of you, too many nowadays act like polite, pedantic robots. :-)
    - deleted 4y ago

Rusky 4y ago

This doesn't mean you don't still have to be panic-safe, though. This is mainly important for unsafe code, because it has to preserve memory safety even in the presence of panics. But it can also be important for safe code in an application that recovers from panics.

celeritascelery 4y ago
You are correct that there are circumstances where you have to consider panic safety. But those are rare. Most code is not unsafe, and catching panics is usually bad practice in Rust (though I am sure there are circumstances where it is needed). In C++ by contrast you have to think about panic safety almost everywhere. Rust’s error handling is a big improvement in that regard.

blub 4y ago

Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants their library to crash their program because someone was too lazy to propagate errors. Which brings me to the point: propagating errors is tedious enough that people are looking for shortcuts, which then cause other problems.

spoiler 4y ago
Somehow I must've been lucky enough to avoid this unwrap abuse in crates I use. I think you maybe meant converting between errors in Rust can be tedious sometimes, but propagation is pretty easy. The conversation is something that generally need's to happen rarely (like a few times per project?), but `thiserror` and `from` make this pretty ergonomic.
burntsushi 4y ago
For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is broken and thus leads to a panic. Nearly all code has runtime invariants in one form or another. The question is what happens when they're broken. In languages that are memory unsafe by default, the answer is often (but not always) "undefined behavior." In languages like Rust, or Python, or Go, the answer is often (but not always) "the process quits." The reality is more complicated than that, but those are a fine first approximation. For example, breaking a runtime invariant doesn't have to lead to undefined behavior or process termination. It can simply result in a logic error that leads to unexpected behavior. Of course, making the issue more complicated is that sometimes 'unwrap()' is abused. And indeed, sometimes it is used in cases where an error ought to be returned. I find this to be generally pretty rare in popular libraries. But the key point here is that you can't just say, "oh I see unwrap() in a library, so now I'm going to scream ABUSE!!!!" It's more complicated than that.
- blub 4y ago
  How is it nonsense if you admit at the end (albeit after a straw-man of me allegedly screaming “abuse”) that it happens? Result is being sold on HN as a great solution to error handling while there’s several crates available which are needed to polish its rough edges, rough edges which have led to e.g. unwrap abuse in the past. It is tedious to shuffle around results, but this is never part of the sales pitch. And for those of us that don’t want to depend on all sorts of crates for the simplest things, that’s the reality. Re your reply “Maybe improve your reading comprehension. I said "(partial) nonsense." Therefore, some of what you said wasn't nonsense. But some is. What a fucking revelation.” Partial nonsense isn’t nonsense by definition, I believe, but I won’t dwell that point. I am surprised seeing a Rustacean being (mildly) offensive and even saying the f-word. I must say that I am proud of you, too many nowadays act like polite, pedantic robots. :-)
  - deleted 4y ago