5 ms·

> Error Handling I've yet to see anyone demonstrate the elegance Rust error handling for anything but the simplest of cases. It's all fun and games and questio

by q3k 2y ago

> Error Handling I've yet to see anyone demonstrate the elegance Rust error handling for anything but the simplest of cases. It's all fun and games and question marks... until you hit this: $ ./app called `Result::unwrap()` on an `Err` value: no such file or directory And then you start investigating and it turns out that the error value comes from somewhere deep in an unknown callstack that got discard by the authors using '?' everywhere. Yes, I know about anyhow and thiserror and eyre and ... ; point is none of this is ever shown in these 'look how elegant error handling is' posts. Come on, let's be a bit more honest with ourselves about Result<T, E> and '?' - it's not a full solution to error handling. After two years I'm sure you've hit this.

constantcrying 2y ago
?ing Errors and never actually handling them is just a terrible practice. In fact it is just as bad as not doing error checking at all. Misusing a mechanism is not a point against the language. What makes this error checking good is that you can use it correctly and it is less cumbersome than the try/catch from C++. >Come on, let's be a bit more honest with ourselves about Result<T, E> and '?' - it's not a full solution to error handling. After two years I'm sure you've hit this. Nothing is ever a full solution. But it is meaningless to talk about this without doing comparisons. Do you think try/catch was the superior solution all along?
- q3k 2y ago
  > ?ing Errors and never actually handling them is just a terrible practice. I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :). > But it is meaningless to talk about this without doing comparisons. Not comparing to other languages/approaches however allows a discussion to stay about Rust and how to make things better instead of yet another fruitless discussion about which language or approach is better in a vacuum. I'm not interested in demonstrating that Rust is better than C++ or vice versa, I'm interested in Rust being good on its own merits.
  - constantcrying 2y ago
    >I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :). Then they are completely misrepresenting what error handling is about. Rusts error handling is good because programs only crash where you allow them to crash. If you are using the error handling correctly, you only crash wherever there is an error you believe should be unrecoverable. >Not comparing to other languages/approaches however allows a discussion to stay about Rust and how to make things better instead of yet another fruitless discussion about which language or approach is better in a vacuum. If you are complaining about the error handling of some language surely the most important and productive thing would be to compare it to the paradigms of other languages. If you are unwilling to consider that someone else is doing something correctly, which you are doing wrong you can't improve. Especially when there are two major paradigms, it seems important to talk about the alternative. What exactly would you change about rusts error handling?
    - Capricorn2481 2y ago
      > Then they are completely misrepresenting what error handling is about That's fine, but the commenter didn't pull this out of nowhere. It's in the article. Your reply makes it sound like you didn't read it, as if OP is giving a rare hypothetical that most Rust programmers don't support. This is common error handling advice in the Rust community. And this is representative of what you may run into when reading other people's code or trying to contribute to their library.
      - constantcrying 2y ago
        I do not think you understood the conversation as I did. Rusts error handling works by defining potential crashes with unwraps. A program never crashes unexpectedly there, as this is where you expect it to crash. The general pattern is fine and widely used, the other commenter did not understand that this kind of behavior results from unwrapping where you really do not want to unwrap.
        q3k 2y ago
- steveklabnik 2y ago
  > ?ing Errors and never actually handling them is just a terrible practice. This isn't true. It really depends. fn main() -> anyhow::Result<()> { can be perfectly good, depending on your needs. What Rust does with error handling is give you flexibility. It's true that means you can make a mess. I myself have a TODO on my current codebase where I'm not exactly happy with what I'm doing at the moment overall. But it can also be very elegant, and more importantly, it doesn't force you into one paradigm that many not be good for your needs, but allows you to decide, which is very important in Rust's conceptual space. I wouldn't want to be forced to use the above signature in a no_std context, for example.
  - constantcrying 2y ago
    >can be perfectly good, depending on your needs. This gives the error to the calling process though. In some sense that means it is handled. I don't think I disagree though, but I think my point still stands. If you do not think about at what point your errors are actually resolved then your program does not have proper error handling. If you unwrap in the middle of your code, you have to accept that crashing there is a possibility, even from an error far away.

by q3k 2y ago

constantcrying 2y ago

?ing Errors and never actually handling them is just a terrible practice. In fact it is just as bad as not doing error checking at all. Misusing a mechanism is not a point against the language. What makes this error checking good is that you can use it correctly and it is less cumbersome than the try/catch from C++. >Come on, let's be a bit more honest with ourselves about Result<T, E> and '?' - it's not a full solution to error handling. After two years I'm sure you've hit this. Nothing is ever a full solution. But it is meaningless to talk about this without doing comparisons. Do you think try/catch was the superior solution all along?

q3k 2y ago
> ?ing Errors and never actually handling them is just a terrible practice. I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :). > But it is meaningless to talk about this without doing comparisons. Not comparing to other languages/approaches however allows a discussion to stay about Rust and how to make things better instead of yet another fruitless discussion about which language or approach is better in a vacuum. I'm not interested in demonstrating that Rust is better than C++ or vice versa, I'm interested in Rust being good on its own merits.
- constantcrying 2y ago
  >I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :). Then they are completely misrepresenting what error handling is about. Rusts error handling is good because programs only crash where you allow them to crash. If you are using the error handling correctly, you only crash wherever there is an error you believe should be unrecoverable. >Not comparing to other languages/approaches however allows a discussion to stay about Rust and how to make things better instead of yet another fruitless discussion about which language or approach is better in a vacuum. If you are complaining about the error handling of some language surely the most important and productive thing would be to compare it to the paradigms of other languages. If you are unwilling to consider that someone else is doing something correctly, which you are doing wrong you can't improve. Especially when there are two major paradigms, it seems important to talk about the alternative. What exactly would you change about rusts error handling?
  - Capricorn2481 2y ago
    > Then they are completely misrepresenting what error handling is about That's fine, but the commenter didn't pull this out of nowhere. It's in the article. Your reply makes it sound like you didn't read it, as if OP is giving a rare hypothetical that most Rust programmers don't support. This is common error handling advice in the Rust community. And this is representative of what you may run into when reading other people's code or trying to contribute to their library.
    - constantcrying 2y ago
      I do not think you understood the conversation as I did. Rusts error handling works by defining potential crashes with unwraps. A program never crashes unexpectedly there, as this is where you expect it to crash. The general pattern is fine and widely used, the other commenter did not understand that this kind of behavior results from unwrapping where you really do not want to unwrap.
      - q3k 2y ago
steveklabnik 2y ago
> ?ing Errors and never actually handling them is just a terrible practice. This isn't true. It really depends. fn main() -> anyhow::Result<()> { can be perfectly good, depending on your needs. What Rust does with error handling is give you flexibility. It's true that means you can make a mess. I myself have a TODO on my current codebase where I'm not exactly happy with what I'm doing at the moment overall. But it can also be very elegant, and more importantly, it doesn't force you into one paradigm that many not be good for your needs, but allows you to decide, which is very important in Rust's conceptual space. I wouldn't want to be forced to use the above signature in a no_std context, for example.
- constantcrying 2y ago
  >can be perfectly good, depending on your needs. This gives the error to the calling process though. In some sense that means it is handled. I don't think I disagree though, but I think my point still stands. If you do not think about at what point your errors are actually resolved then your program does not have proper error handling. If you unwrap in the middle of your code, you have to accept that crashing there is a possibility, even from an error far away.