3 ms·

I don't consider this an anti-pattern, but part of the flexibility gained by Go's lightweight approach to error handling. I believe Go was even designed with th

I don't consider this an anti-pattern, but part of the flexibility gained by Go's lightweight approach to error handling. I believe Go was even designed with this use case in mind (the standard library uses it in many places, and I don't consider their documentation about it "snarky"). Sometimes you want to return a partial result along with an error. Go's idiom of returning multiple values, with the final value being an error, allows this situation to be easily supported.

monocasa 3y ago
Except in the case I'm talking about, there was a resource to be reclaimed, the GC didn't cover it. And if you wanted to do that in rust, that's a valid thing too, either as using a tuple instead of a sum type, or a tuple in the Err side of a result. You can describe what you're trying to do simply with the function signature.
lmm 3y ago
> Sometimes you want to return a partial result along with an error. Sometimes you do, and there are types that represents that. Having a single type that is almost always used a certain way but occasionally used subtly differently is a trap waiting to bite you.
- beautron 3y ago
  I've been using Go for almost a decade, and I don't recall this ever biting me. It doesn't feel like a trap. Go has a convention of documenting each function with a comment (which is adhered to by the standard library, my own code, and any other code I'd consider worthy of depending on). So when I think this subtlety matters, I check the documentation. Usually I don't care either way: When I get a non-nil error, I typically don't care about the other result (whether partial or the zero value). The distinction rarely matters in practice (and when it does, the documentation is there). I think this simplicity is the right tradeoff (vs. being burdened with more types to think about).
  - lmm 3y ago
    How is a type more of a burden than documentation? You're saying that consistent documentation is a good thing, but types enforce more consistency and integrate better with tools.
    - beautron 3y ago
      Documentation has immense value beyond just this specific error situation. Its a burden worth taking on regardless of how errors are handled. So it's not that a type is more of a burden than documentation, but rather that a type is an additional burden (since we're taking on the documentation burden either way). I like that Go's error handling is simple enough that I can keep all its rules in my head. And I like that the other parts of Go are simple like that too. It allows me to easily know exactly what is going on at the language level (while my attention is focused on higher levels).
      - lmm 3y ago
        The more you can shift into types the less you need to put in ad-hoc documentation, so it's not an extra burden. Conversely, if you "keep the language level rules simple" by shifting more stuff from the types into the documentation, that's not making it easier to think about IME - the more you can shift into the lower levels the better, so the documentation can focus on the higher-level things you weren't able to encode in the types.
  - et1337 3y ago
    I’ve been bitten by it in production. Whenever I see this partial result pattern, it’s always a function that USUALLY returns nil plus an error. In one special case, it returns a partial result plus an error. This is a nil pointer panic waiting to happen.
    - beautron 3y ago
      The caller can check if the result != nil. If I get a result that came with a non-nil error, and I still plan to do something with the result, then it seems natural to think about the possibility that the result might be nil. I would consult the function's documentation, and maybe its source, and then maybe put in a nil check. This is too rare a problem to be worth adding complexity to the language. There needs to be a big payoff for adding complexity. A language gets hard to use if it adds micro-complexities all over the place for the sake of preventing rare programming mistakes.

monocasa 3y ago

Except in the case I'm talking about, there was a resource to be reclaimed, the GC didn't cover it. And if you wanted to do that in rust, that's a valid thing too, either as using a tuple instead of a sum type, or a tuple in the Err side of a result. You can describe what you're trying to do simply with the function signature.

lmm 3y ago

> Sometimes you want to return a partial result along with an error. Sometimes you do, and there are types that represents that. Having a single type that is almost always used a certain way but occasionally used subtly differently is a trap waiting to bite you.

beautron 3y ago
I've been using Go for almost a decade, and I don't recall this ever biting me. It doesn't feel like a trap. Go has a convention of documenting each function with a comment (which is adhered to by the standard library, my own code, and any other code I'd consider worthy of depending on). So when I think this subtlety matters, I check the documentation. Usually I don't care either way: When I get a non-nil error, I typically don't care about the other result (whether partial or the zero value). The distinction rarely matters in practice (and when it does, the documentation is there). I think this simplicity is the right tradeoff (vs. being burdened with more types to think about).
- lmm 3y ago
  How is a type more of a burden than documentation? You're saying that consistent documentation is a good thing, but types enforce more consistency and integrate better with tools.
  - beautron 3y ago
    Documentation has immense value beyond just this specific error situation. Its a burden worth taking on regardless of how errors are handled. So it's not that a type is more of a burden than documentation, but rather that a type is an additional burden (since we're taking on the documentation burden either way). I like that Go's error handling is simple enough that I can keep all its rules in my head. And I like that the other parts of Go are simple like that too. It allows me to easily know exactly what is going on at the language level (while my attention is focused on higher levels).
    - lmm 3y ago
      The more you can shift into types the less you need to put in ad-hoc documentation, so it's not an extra burden. Conversely, if you "keep the language level rules simple" by shifting more stuff from the types into the documentation, that's not making it easier to think about IME - the more you can shift into the lower levels the better, so the documentation can focus on the higher-level things you weren't able to encode in the types.
- et1337 3y ago
  I’ve been bitten by it in production. Whenever I see this partial result pattern, it’s always a function that USUALLY returns nil plus an error. In one special case, it returns a partial result plus an error. This is a nil pointer panic waiting to happen.
  - beautron 3y ago
    The caller can check if the result != nil. If I get a result that came with a non-nil error, and I still plan to do something with the result, then it seems natural to think about the possibility that the result might be nil. I would consult the function's documentation, and maybe its source, and then maybe put in a nil check. This is too rare a problem to be worth adding complexity to the language. There needs to be a big payoff for adding complexity. A language gets hard to use if it adds micro-complexities all over the place for the sake of preventing rare programming mistakes.