3 ms·

That's a really unfair characterization of Go's error handling, and something only really novice Go developers do. https://dave.cheney.net/2016/04/27/dont-just

That's a really unfair characterization of Go's error handling, and something only really novice Go developers do. https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully https://dave.cheney.net/2016/04/27/dont-just-check-errors-ha...

monocasa 7y ago
And pretty much every production golang codebase I've seen.
weberc2 7y ago
I've been using Go for 7 years and I don't think this is a mischaracterization at all. I definitely don't think it's something "only really novice Go developers do"--I see it all the time, including in popular open source libraries and even the standard library. I don't think it's contentious that Go's error handling needs some improvement (by which I mean "more standard, structured error handling" and not "syntax support for eliminating error handling boilerplate"--the latter is more contentious as far as I'm aware).
TheDong 7y ago
Every time you use `fmt.Errorf` and `if err != nil { return nil, err }`, you're returning a stringly typed error up the stack. The entire stdlib does this. An error stack is never present from stdlib functions' errors, and third party libraries I see it just as infrequently. If only novice go devs do that, than the entire go core team are novices, as well as the authors of popular go projects like kubernetes and docker.
- skybrian 7y ago
  "Stringly typed" means literally a string. Go doesn't always distinguish between errors, but the error type does distinguish errors from non-errors and that's important. It seems better to have coarse-grained types than to standardize the wrong type hierarchy?
pjmlp 7y ago
Even some std packages do it.
- tyri_kai_psomi 7y ago
  The std lib is not the paragon of go virtue as some people make it out to be. The maintainers have been frank with some of the mistakes and things they'd do differently now but because they place the Go 1 promise above everything else (a good thing), it has some patterns not many would recommend these days, error handling among them.
  - monocasa 7y ago
    And kubernetes, docker, golang.com/x/*, etc. And it's not like they couldn't add better types to errors without breaking backwards compat. Returning a type that implements error instead of fmt.Errorf doesn't break existing semantics.
cyphar 7y ago
Almost every large Go codebase does this with very few exceptions. Until the advent of github.com/pkg/errors there wasn't an easy way to uniformly implement error chaining so people would just prepend strings (if they have any context at all) and used fmt.Errorf religiously. These days, fmt.Errorf is still used but now you can in principle root-cause errors with errors.Cause -- unfortunately many Go libraries do not use github.com/pkg/errors (because of the nested vendor problem that existed for many years) and so you are stuck if you want to root-cause an error in an older library. All of that being said, modern Go (written in the past few years) could avoid these pitfalls. But very few production codebases were both written in the past few years and only use libraries written in the past few years. I've worked on Go codebases for the past 5-6 years.

monocasa 7y ago

And pretty much every production golang codebase I've seen.

weberc2 7y ago

I've been using Go for 7 years and I don't think this is a mischaracterization at all. I definitely don't think it's something "only really novice Go developers do"--I see it all the time, including in popular open source libraries and even the standard library. I don't think it's contentious that Go's error handling needs some improvement (by which I mean "more standard, structured error handling" and not "syntax support for eliminating error handling boilerplate"--the latter is more contentious as far as I'm aware).

TheDong 7y ago

Every time you use `fmt.Errorf` and `if err != nil { return nil, err }`, you're returning a stringly typed error up the stack. The entire stdlib does this. An error stack is never present from stdlib functions' errors, and third party libraries I see it just as infrequently. If only novice go devs do that, than the entire go core team are novices, as well as the authors of popular go projects like kubernetes and docker.

skybrian 7y ago
"Stringly typed" means literally a string. Go doesn't always distinguish between errors, but the error type does distinguish errors from non-errors and that's important. It seems better to have coarse-grained types than to standardize the wrong type hierarchy?

pjmlp 7y ago

Even some std packages do it.

tyri_kai_psomi 7y ago
The std lib is not the paragon of go virtue as some people make it out to be. The maintainers have been frank with some of the mistakes and things they'd do differently now but because they place the Go 1 promise above everything else (a good thing), it has some patterns not many would recommend these days, error handling among them.
- monocasa 7y ago
  And kubernetes, docker, golang.com/x/*, etc. And it's not like they couldn't add better types to errors without breaking backwards compat. Returning a type that implements error instead of fmt.Errorf doesn't break existing semantics.

cyphar 7y ago

Almost every large Go codebase does this with very few exceptions. Until the advent of github.com/pkg/errors there wasn't an easy way to uniformly implement error chaining so people would just prepend strings (if they have any context at all) and used fmt.Errorf religiously. These days, fmt.Errorf is still used but now you can in principle root-cause errors with errors.Cause -- unfortunately many Go libraries do not use github.com/pkg/errors (because of the nested vendor problem that existed for many years) and so you are stuck if you want to root-cause an error in an older library. All of that being said, modern Go (written in the past few years) could avoid these pitfalls. But very few production codebases were both written in the past few years and only use libraries written in the past few years. I've worked on Go codebases for the past 5-6 years.