3 ms·

> ?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 ev

by 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
      > the other commenter did not understand [...] That's not the case, I understand the issue at hand quite well. Please don't do this. I didn't reply to your other comment because this conversation isn't/wasn't going anywhere.
      - constantcrying 2y ago
        Oh, I presumed you didn't because, even when I asked you, you didn't point out why you disliked it, what you would improve or how it compared to alternatives.

by q3k 2y ago

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
    > the other commenter did not understand [...] That's not the case, I understand the issue at hand quite well. Please don't do this. I didn't reply to your other comment because this conversation isn't/wasn't going anywhere.
    - constantcrying 2y ago
      Oh, I presumed you didn't because, even when I asked you, you didn't point out why you disliked it, what you would improve or how it compared to alternatives.