4 ms·

I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't really care about that.

by Mond_ 1y ago

I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't really care about that. How about: - Errors can be dropped silently or accidentally ignored - function call results cannot be stored or passed around easily due to not being values - errors.Is being necessary and the whole thing with 'nested' errors being a strange runtime thing that interacts poorly with the type system - switching on errors being hard - usage of sentinel values in the standard library - poor interactions with generics making packages such as errgroup necessary Did I miss anything?

GiorgioG 1y ago
Just remember it took FOREVER for Go to support some form of generics. Go evolution happens at a glacial pace. That's a feature, not a bug....to many.
neild 1y ago
> I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't believe this claim is made anywhere. We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).
- pas 1y ago
  writing a small book on the topic and somehow missing it is the point, not that technically the text is claiming it, the subtext is doing it.
VirusNewbie 1y ago
Agreed, 100%. We're both Googlers here and this is so disappointing to be let down again by the Go team.
closeparen 1y ago
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.
- cedws 1y ago
  Test coverage as a target metric is stupid.
  - deleted 1y ago
    [deleted]
  - MeetingsBrowser 1y ago
    why?
    - cedws 1y ago
      Goodhart's law, and because there are code paths not worth testing.
      - MeetingsBrowser 1y ago
        If its not worth testing delete it. Which target metrics do you consider to be good despite Goodhart's law?
  - g7r 1y ago
    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.
- ncruces 1y ago
  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. https://github.com/dave/courtney https://github.com/dave/courtney
SkepticalWhale 1y ago
I agree with item #1, but it can be mitigated somewhat with dev tools like errcheck: https://github.com/kisielk/errcheck?tab=readme-ov-file https://github.com/kisielk/errcheck?tab=readme-ov-file

by Mond_ 1y ago

GiorgioG 1y ago

Just remember it took FOREVER for Go to support some form of generics. Go evolution happens at a glacial pace. That's a feature, not a bug....to many.

neild 1y ago

> I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't believe this claim is made anywhere. We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).

pas 1y ago
writing a small book on the topic and somehow missing it is the point, not that technically the text is claiming it, the subtext is doing it.

VirusNewbie 1y ago

Agreed, 100%. We're both Googlers here and this is so disappointing to be let down again by the Go team.

closeparen 1y ago

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.

cedws 1y ago
Test coverage as a target metric is stupid.
- deleted 1y ago
  [deleted]
- MeetingsBrowser 1y ago
  why?
  - cedws 1y ago
    Goodhart's law, and because there are code paths not worth testing.
    - MeetingsBrowser 1y ago
      If its not worth testing delete it. Which target metrics do you consider to be good despite Goodhart's law?
- g7r 1y ago
  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.
ncruces 1y ago
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. https://github.com/dave/courtney https://github.com/dave/courtney

SkepticalWhale 1y ago

I agree with item #1, but it can be mitigated somewhat with dev tools like errcheck: https://github.com/kisielk/errcheck?tab=readme-ov-file https://github.com/kisielk/errcheck?tab=readme-ov-file