90% of working professionally in Go is contriving test cases to achieve statement coverage over each error return branch, something no one would ever do in a language with exceptions.
Maybe so. However, it is really really handy when you are assessing the completeness of your tests using code coverage, and can clearly see unhandled negative paths. And then you can decide whether some of them deserve dedicated tests or not.
It this really bothers you, convince your team to use courtney and focus on the more relevant error branches: the ones where (1) a novel error value is produced or (2) handled rather than those that simply bubble it up.
