3 ms·

I think it is a language issue, if the language makes a bare return much easier than the alternative, then that's what people will be inclined to do.

by arccy 1y ago

nixpulvis 1y ago
When I say it's not a language issue, that's because I can imagine a crate or design pattern filling this role, and I cannot as easily imagine a change to the language itself that would make it better. But I also haven't given this as much thought as it deserves.
- arccy 1y ago
  getting rid of ? might help...
  - nixpulvis 1y ago
    I don't think that helps, there are a lot of intermediate steps that rightfully propagate or union errors and `?` makes that a lot easier. The issue is figuring out when to not do that and wrap a low level error with a higher level error without losing the critical information and making things to generic.
RealityVoid 1y ago
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.)
deleted 1y ago
[deleted]

I think it is a language issue, if the language makes a bare return much easier than the alternative, then that's what people will be inclined to do.

by arccy 1y ago

I think it is a language issue, if the language makes a bare return much easier than the alternative, then that's what people will be inclined to do.

nixpulvis 1y ago

When I say it's not a language issue, that's because I can imagine a crate or design pattern filling this role, and I cannot as easily imagine a change to the language itself that would make it better. But I also haven't given this as much thought as it deserves.

arccy 1y ago
getting rid of ? might help...
- nixpulvis 1y ago
  I don't think that helps, there are a lot of intermediate steps that rightfully propagate or union errors and `?` makes that a lot easier. The issue is figuring out when to not do that and wrap a low level error with a higher level error without losing the critical information and making things to generic.

RealityVoid 1y ago

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.)

deleted 1y ago

[deleted]