8 ms·

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

zemo 14y ago
it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.
- chengiz 14y ago
  How does it force you to handle errors? Cant you choose to ignore the return value?
  - osi 14y ago
    You can absolutely ignore it. Or in the case of the Write call, which only returns an error, just never assign it. go's error handling is nice, but since it doesn't force it on you, it leads to errors of omission.
    - skybrian 14y ago
      If the function returns a useful value and an error then you'll have to assign to error to "_" to ignore it, which is a pretty big hint to the reviewer that it's being suppressed. So in cases where you want to "force" error checking, returning multiple values is probably good enough.
- awj 14y ago
  > It forces you to handle errors at the call site and makes diapers unimplementable. I don't see how the latter is true. What's the practical difference between wrapping a function call in a try/(no-op)catch and entirely ignoring the error return value?
dhconnelly 14y ago
Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.
- ntrel 14y ago
  The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed. This requires some flow analysis, but brings real benefit and safety.
  - redbad 14y ago
    The problem is it's no better than C Multiple return values are pretty clearly better than C. The comma-OK or comma-err idiom is verbose, but powerful and unambiguous.
    - AnswerAndForget 14y ago
      A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception: http://www.reddit.com/r/programming/comments/w1ig0/things_i_like_about_programming_in_go_john/c59vy33 http://www.reddit.com/r/programming/comments/w1ig0/things_i_...
      - jongraehl 14y ago
        There is no reason for any new language to lack tagged union types. It disturbs me that Brian Cox rejects a simple, proven language feature that he does not even understand, even though it would take all of 2 minutes of searching/reading to understand. I'm sure he spent at least that long composing the replies in that thread, never moving past the ego-threat of "will Go ever have X?" to honestly evaluate the question.
swdunlop 14y ago
Right. Early in learning golang, many people will get tired of typing: ..., err := doStuff() if err != nil { return err } The usual text editor features, like templates, reduce the typing, but the point is that the programmer must think, each time, about what they want to do when a function fails. This can become either a really good habit, or a distraction, depending on your perspective and problem domain. When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.

especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?

zemo 14y ago

it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.

chengiz 14y ago
How does it force you to handle errors? Cant you choose to ignore the return value?
- osi 14y ago
  You can absolutely ignore it. Or in the case of the Write call, which only returns an error, just never assign it. go's error handling is nice, but since it doesn't force it on you, it leads to errors of omission.
  - skybrian 14y ago
    If the function returns a useful value and an error then you'll have to assign to error to "_" to ignore it, which is a pretty big hint to the reviewer that it's being suppressed. So in cases where you want to "force" error checking, returning multiple values is probably good enough.
awj 14y ago
> It forces you to handle errors at the call site and makes diapers unimplementable. I don't see how the latter is true. What's the practical difference between wrapping a function call in a try/(no-op)catch and entirely ignoring the error return value?

dhconnelly 14y ago

Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.

ntrel 14y ago
The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed. This requires some flow analysis, but brings real benefit and safety.
- redbad 14y ago
  The problem is it's no better than C Multiple return values are pretty clearly better than C. The comma-OK or comma-err idiom is verbose, but powerful and unambiguous.
  - AnswerAndForget 14y ago
    A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception: http://www.reddit.com/r/programming/comments/w1ig0/things_i_like_about_programming_in_go_john/c59vy33 http://www.reddit.com/r/programming/comments/w1ig0/things_i_...
    - jongraehl 14y ago
      There is no reason for any new language to lack tagged union types. It disturbs me that Brian Cox rejects a simple, proven language feature that he does not even understand, even though it would take all of 2 minutes of searching/reading to understand. I'm sure he spent at least that long composing the replies in that thread, never moving past the ego-threat of "will Go ever have X?" to honestly evaluate the question.

swdunlop 14y ago

Right. Early in learning golang, many people will get tired of typing: ..., err := doStuff() if err != nil { return err } The usual text editor features, like templates, reduce the typing, but the point is that the programmer must think, each time, about what they want to do when a function fails. This can become either a really good habit, or a distraction, depending on your perspective and problem domain. When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.