5 ms·

I’m surprised they didn’t mention the horrible error handling as something they regret…

righthand 3y ago
Because it’s neither horrible nor regrettable, it just doesn’t cater to your perfect idea of what it should be. It’s a smart way to encourage people to handle errors.
- bananapub 3y ago
  you think it's "smart" to encourage a large fraction of function calls to have if err != nil { return nil, err } after it? really? you don't think it's just a very simple way to do it without having to do a lot of work in the language? and then make everyone use a linter to avoid bugs? oh and you can't always literally do 'return nil, err' because strings have to be ""? it's certainly defensible as a minimalist approach, claiming it's actually good or smart or ideal is a pretty weird take.
  - righthand 3y ago
    You think it’s “a lot of work” to write an if statement? Any of the proposed variations have shown to be either different syntax (weak valueless change) or would allow people to ignore handling errors. You can’t always return nil? is that a complaint that you are required to do things differently for data types that require it inside of a complaint about doing things the same? It’s not a weird take, things have tradeoffs, this is a tradeoff of using Go.
    - unscaled 3y ago
      It's not a lot of work, you can just let the IDE spew it off for you and feel like a certified J2EE programmer circa 2003 who lets the IDE write everything for them. But yeah, writing code is not the problem. Reading the code is. I think having 60% of your lines of code being: if err != nil { return err } Does make the code a tad bit less readable.
      - righthand 3y ago
        So then it’s less readable because you have to process a simple error return? I won’t even comment on the 60% of code is error handling, that sounds like code that needs refactoring.
  - yencabulator 3y ago
    That's not what is encouraged. What is encouraged is actually handling the error, and adding information about the operation, to it.
- unscaled 3y ago
  More precisely because "they" are Rob Pike, and Rob Pike doesn't seem to think error handling in Go is horrible. Other members of the Go Team (Robert Griesemer, Russ Cox) trialed out several solutions for this problem, but this issue was just too controversial within the community.
Thaxll 3y ago
It's not horrible, it's ok and a bit repetitive. Really the whole thing about error handling in Go is overblown.
- righthand 3y ago
  It’s a bit repetitive but so is writing `for i, v := range n {}` everywhere. Code loops and repeats syntax all the time, so what? Argument doesn’t hold water for me (not attacking).
  - lmm 3y ago
    Repetitive code is a language flaw IMO. There are certainly more concise alternatives to the common case of that loop construct in many languages.
    - righthand 3y ago
      Then people should use those languages. From the beginning Go has been about simplicity and utility, not about providing multiple patterns and alternate syntax. I would also argue that repetitive code is a failure of the engineer who implemented it. If writing code is repetitive then people may want to look into generating it instead.
    - aatd86 3y ago
      It's an interesting opinion. I tend to believe there can be value in repetitive code patterns for recognition. It can make a language easier to read and understand although a bit more tedious to write. It's especially interesting nowadays when LLM models can write parts of it. It alleviates the writing part.
- eweise 3y ago
  Because its repetitive its leads to incorrect code. I've seen more swallowed errors in Go than other languages.
  - 13415 3y ago
deleted 3y ago
[deleted]

Because it’s neither horrible nor regrettable, it just doesn’t cater to your perfect idea of what it should be. It’s a smart way to encourage people to handle errors.

bananapub 3y ago
you think it's "smart" to encourage a large fraction of function calls to have if err != nil { return nil, err } after it? really? you don't think it's just a very simple way to do it without having to do a lot of work in the language? and then make everyone use a linter to avoid bugs? oh and you can't always literally do 'return nil, err' because strings have to be ""? it's certainly defensible as a minimalist approach, claiming it's actually good or smart or ideal is a pretty weird take.
- righthand 3y ago
  You think it’s “a lot of work” to write an if statement? Any of the proposed variations have shown to be either different syntax (weak valueless change) or would allow people to ignore handling errors. You can’t always return nil? is that a complaint that you are required to do things differently for data types that require it inside of a complaint about doing things the same? It’s not a weird take, things have tradeoffs, this is a tradeoff of using Go.
  - unscaled 3y ago
    It's not a lot of work, you can just let the IDE spew it off for you and feel like a certified J2EE programmer circa 2003 who lets the IDE write everything for them. But yeah, writing code is not the problem. Reading the code is. I think having 60% of your lines of code being: if err != nil { return err } Does make the code a tad bit less readable.
    - righthand 3y ago
      So then it’s less readable because you have to process a simple error return? I won’t even comment on the 60% of code is error handling, that sounds like code that needs refactoring.
- yencabulator 3y ago
  That's not what is encouraged. What is encouraged is actually handling the error, and adding information about the operation, to it.
unscaled 3y ago
More precisely because "they" are Rob Pike, and Rob Pike doesn't seem to think error handling in Go is horrible. Other members of the Go Team (Robert Griesemer, Russ Cox) trialed out several solutions for this problem, but this issue was just too controversial within the community.

Thaxll 3y ago

It's not horrible, it's ok and a bit repetitive. Really the whole thing about error handling in Go is overblown.

righthand 3y ago
It’s a bit repetitive but so is writing `for i, v := range n {}` everywhere. Code loops and repeats syntax all the time, so what? Argument doesn’t hold water for me (not attacking).
- lmm 3y ago
  Repetitive code is a language flaw IMO. There are certainly more concise alternatives to the common case of that loop construct in many languages.
  - righthand 3y ago
    Then people should use those languages. From the beginning Go has been about simplicity and utility, not about providing multiple patterns and alternate syntax. I would also argue that repetitive code is a failure of the engineer who implemented it. If writing code is repetitive then people may want to look into generating it instead.
  - aatd86 3y ago
    It's an interesting opinion. I tend to believe there can be value in repetitive code patterns for recognition. It can make a language easier to read and understand although a bit more tedious to write. It's especially interesting nowadays when LLM models can write parts of it. It alleviates the writing part.
eweise 3y ago
Because its repetitive its leads to incorrect code. I've seen more swallowed errors in Go than other languages.
- 13415 3y ago

deleted 3y ago

[deleted]