5 ms·

What I worry is that this problem is overhyped from new go coders (or people who took a look at go and that's it). The explicit error handling blends into the b

What I worry is that this problem is overhyped from new go coders (or people who took a look at go and that's it). The explicit error handling blends into the background so fast. It's never been an issue for me while developing in the past 4 years on go based systems.

mav3rick 7y ago
Rust provides really good syntactic sugar that doesn't compromise on catching errors. I get Go is inspired by C, but sometimes it seems too stringent on avoiding any and everything that may make life easier for readers and programmers.
crimsonalucard 7y ago
You're use to using a hammer on a screw. It's never been an issue for you for four years. It's still a big issue overall.
- xmprt 7y ago
  You're exactly the problem the commenter is talking about. I got used to it within a month and while I would appreciate better error handling (if that even exists), I don't think the solution should be rushed and I don't think the way Java handles it is right.
  - crimsonalucard 7y ago
    I agree, but leaving it because people are used to it is not the right solution imo.
KirinDave 7y ago
This is the real danger of the pattern, isn't it? It fades into the background, lulling your eyes into skipping over what's potentially a major source of bugs.
- tylerFowler 7y ago
  Not more than seeing that an existing function you're extending or otherwise working on throwing its exceptions and saying "Ok I guess something above this will catch my exceptions" and learning to take that at face value. Or at least that's been my experience working on large scale Java projects with teams. From my experience with Go I find that only these lines fade into the background: something, err := someFunc() if err != nil { return nil, err } I find that whenever any actual error handling logic beyond forwarding tends to really jump out at me in code reviews and such.
- tptacek 7y ago
  It's hard to believe an explicit error check could be more lulling than the invisible exceptions most mainstream languages use.
  - KirinDave 7y ago
    The thing is, a lack of error handling code is a clear sign of deferral. No action is a "pass" up the stack, ultimately to the top loop. In Go, a lack of action is called out, but the policy for pass/keep is explicit on every choice and sometimes can be subtle (for examples of you try to do an http call expecting an error, that looks nearly identical to code that does the opposite. I think that the try() stuff removing the humdrum repetition is a good idea precisely because it makes all explicit error handling stand out like a beacon. I might name it "pass" or something but that's not as important. If I recall correctly, it vaguely resembles a solution you recommended to me on at least one occasion. Keeping things as they are seems to me like the worst possible option.
    - tptacek 7y ago
      I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.

mav3rick 7y ago

Rust provides really good syntactic sugar that doesn't compromise on catching errors. I get Go is inspired by C, but sometimes it seems too stringent on avoiding any and everything that may make life easier for readers and programmers.

crimsonalucard 7y ago

You're use to using a hammer on a screw. It's never been an issue for you for four years. It's still a big issue overall.

xmprt 7y ago
You're exactly the problem the commenter is talking about. I got used to it within a month and while I would appreciate better error handling (if that even exists), I don't think the solution should be rushed and I don't think the way Java handles it is right.
- crimsonalucard 7y ago
  I agree, but leaving it because people are used to it is not the right solution imo.

KirinDave 7y ago

This is the real danger of the pattern, isn't it? It fades into the background, lulling your eyes into skipping over what's potentially a major source of bugs.

tylerFowler 7y ago
Not more than seeing that an existing function you're extending or otherwise working on throwing its exceptions and saying "Ok I guess something above this will catch my exceptions" and learning to take that at face value. Or at least that's been my experience working on large scale Java projects with teams. From my experience with Go I find that only these lines fade into the background: something, err := someFunc() if err != nil { return nil, err } I find that whenever any actual error handling logic beyond forwarding tends to really jump out at me in code reviews and such.
tptacek 7y ago
It's hard to believe an explicit error check could be more lulling than the invisible exceptions most mainstream languages use.
- KirinDave 7y ago
  The thing is, a lack of error handling code is a clear sign of deferral. No action is a "pass" up the stack, ultimately to the top loop. In Go, a lack of action is called out, but the policy for pass/keep is explicit on every choice and sometimes can be subtle (for examples of you try to do an http call expecting an error, that looks nearly identical to code that does the opposite. I think that the try() stuff removing the humdrum repetition is a good idea precisely because it makes all explicit error handling stand out like a beacon. I might name it "pass" or something but that's not as important. If I recall correctly, it vaguely resembles a solution you recommended to me on at least one occasion. Keeping things as they are seems to me like the worst possible option.
  - tptacek 7y ago
    I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.