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.
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.
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.
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?
"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.
