3 ms·

its of course hyperbolic but frequent enough in any substantial codebase to be a wart on the language.

• randomdata 3y ago
  Most codebases would not justify the use of 'return nil, err' at all. The language certainly isn't going to stop you, but you are going to make life miserable for future developers if you do so. There are rare circumstances where it is the right thing, but if you are seeing more than one or two instances in a substantial codebase, something isn't right. If it is a common occurrence, and you are not purposefully trying to demonstrate your hatred of future developers, you've no doubt introduced way too much unnecessary complexity – which too is going to make life miserable for future developers.
  • dd82 3y ago
    would love to see some examples you cite. This pattern is prevalent in all golang I've seen, whether in libs or work. And I've only been working in the language full time for three months.
    • randomdata 3y ago
      I would love to have the original question answered. Perhaps you (or the people who have contributed the code of which you speak) have stumbled upon some solution to the coupling problem, in which case I would then understand the choice. Frankly, the entire Go community is no doubt keen to hear it. The 'try' proposal fell apart because nobody could figure out a good solution to that problem at the time, and could not find justification for a whole new feature for rare occasions. If `if err != nil { return nil, err }` were to actually become tenable in most cases then said proposal could be revived based on your information. It was otherwise well received.
      • bvrmn 3y ago
        It would be wonderful to see your non-coupled design without middle layers knowing about top context to handle errors without bubbling it up. It already sounds like a failure.
        • randomdata 3y ago
          I must misunderstand, but your request does, indeed, sound like a failure – and not at all related to the discussion taking place. Perhaps you could explain how "middle layers" and "top context" fit?
          • closeparen 3y ago
            "Handling" an error, without propagating it to the caller, can only mean deciding that the thing attempted didn't really need to happen. This situation is extremely rare: if it's appropriate to swallow an error, you may as well not even attempt the thing. We don't normally write "opportunistic" functionality into our software. But when we do, it's the jurisdiction of the caller to say that the it doesn't matter if the called function fails. It's almost never appropriate for the callee to decide to eat its own failures.