4 ms·

Easiest error handling is just .unwrap(). It's true you can just leave it messy like that, but it at least leaves you an obvious trail where you can go and clea

Easiest error handling is just .unwrap(). It's true you can just leave it messy like that, but it at least leaves you an obvious trail where you can go and clean up the error reaction.

nixpulvis 1y ago
Easier yes; better absolutely not. A user should not be given an unwrap error and expected to read the code to figure out what went wrong. In general, if you're making serious software, you shouldn't assume source knowledge at all in user facing messaging.
- MangoToupe 1y ago
  This seems incredibly bad faith—using "unwrap" is closer to using an assert than it is at being "user facing messaging". Asserts don't typically come with manuals explaining what the user should do to fix the software. We all have moments when we're developing software and haven't fully developed the domain. Not requiring exhaustive error handling during this process is a massive help. Obviously, fully enumerated errors are good, and catering diagnostics to the users is even better. But there's more to software than shipping perfect code.
  - nixpulvis 1y ago
    I do not understand your point. Are you saying more code should use asserts for catching error cases? Nobody's saying perfection is 100% required, but there are ideals and we should aim for them and design with principle. One of those principals should be quality error messages. Hell, the rust compiler itself is a great case study for how improving error messages for users massively helps with adoption and quality of life. It's pretty rare that you hit an internal compiler error (ICE) too which is nice.
    - MangoToupe 1y ago
      I'm certainly not against high-quality diagnostics, I'm just saying that few people expect an unwrap to be sufficient for this, and it's odd to me to look at an unwrap and see it as error messaging (outside of what an assert is supposed to provide—eg a clear inconsistency in logic a developer needs to interpret). But to figure out which errors you need to appropriately parameterize and pass up the stack, you first need to understand what you're building. Without unwrap, we would basically have to engage in exhaustive enumeration as we develop. Which is fine, if you're willing to put that effort in! But that's part of why things like Haskell can struggle to win people over—for better or worse, half-broken code (semantically, in domain terms) that compiles and runs is a powerful tool mid-feature. But yes, this does require that people care about diagnostics to begin with. I don't think that's worth forcing; most of us develop this instinct through frustration at dealing with the fallout of someone not caring. (And FWIW I find the combination of explicitly-structured Results that are manually passed up the stack with RAII to be a very, very sweet spot for development velocity, and also easy to teach. I very much prefer this to both exceptions and go's approach.)
- RealityVoid 1y ago
  I did not claim anything about "better" - I just said that if you don't want to deal with errors, you unwrap it - it's the go-to behavior if you just want to make it build. That is what the language makes "much easier than the alternative". If you want to make it robust, you can go through the unwraps and handle them with the care they deserve. I agree about needing to have care about it, but I was fighting the claim that the poor error handling is an issue with the language.

Easiest error handling is just .unwrap(). It's true you can just leave it messy like that, but it at least leaves you an obvious trail where you can go and clean up the error reaction.

nixpulvis 1y ago

Easier yes; better absolutely not. A user should not be given an unwrap error and expected to read the code to figure out what went wrong. In general, if you're making serious software, you shouldn't assume source knowledge at all in user facing messaging.

MangoToupe 1y ago
This seems incredibly bad faith—using "unwrap" is closer to using an assert than it is at being "user facing messaging". Asserts don't typically come with manuals explaining what the user should do to fix the software. We all have moments when we're developing software and haven't fully developed the domain. Not requiring exhaustive error handling during this process is a massive help. Obviously, fully enumerated errors are good, and catering diagnostics to the users is even better. But there's more to software than shipping perfect code.
- nixpulvis 1y ago
  I do not understand your point. Are you saying more code should use asserts for catching error cases? Nobody's saying perfection is 100% required, but there are ideals and we should aim for them and design with principle. One of those principals should be quality error messages. Hell, the rust compiler itself is a great case study for how improving error messages for users massively helps with adoption and quality of life. It's pretty rare that you hit an internal compiler error (ICE) too which is nice.
  - MangoToupe 1y ago
    I'm certainly not against high-quality diagnostics, I'm just saying that few people expect an unwrap to be sufficient for this, and it's odd to me to look at an unwrap and see it as error messaging (outside of what an assert is supposed to provide—eg a clear inconsistency in logic a developer needs to interpret). But to figure out which errors you need to appropriately parameterize and pass up the stack, you first need to understand what you're building. Without unwrap, we would basically have to engage in exhaustive enumeration as we develop. Which is fine, if you're willing to put that effort in! But that's part of why things like Haskell can struggle to win people over—for better or worse, half-broken code (semantically, in domain terms) that compiles and runs is a powerful tool mid-feature. But yes, this does require that people care about diagnostics to begin with. I don't think that's worth forcing; most of us develop this instinct through frustration at dealing with the fallout of someone not caring. (And FWIW I find the combination of explicitly-structured Results that are manually passed up the stack with RAII to be a very, very sweet spot for development velocity, and also easy to teach. I very much prefer this to both exceptions and go's approach.)
RealityVoid 1y ago
I did not claim anything about "better" - I just said that if you don't want to deal with errors, you unwrap it - it's the go-to behavior if you just want to make it build. That is what the language makes "much easier than the alternative". If you want to make it robust, you can go through the unwraps and handle them with the care they deserve. I agree about needing to have care about it, but I was fighting the claim that the poor error handling is an issue with the language.