7 ms·

Sorry for off-topic question, but is this considered good golang code ? https://github.com/wallix/awless/blob/master/stats/stats.go https://github.com/wallix/aw

by jsk2600 10y ago

Sorry for off-topic question, but is this considered good golang code ? https://github.com/wallix/awless/blob/master/stats/stats.go https://github.com/wallix/awless/blob/master/stats/stats.go I'm considering learning go but amount of 'return err' and 'return nil, 0, err' is instant turn-off. Is this best-practice error handling in go ? Thanks !

spullara 10y ago
That is actually how you do error handling in go. Just awful IMHO.
sly010 10y ago
It's pretty normal and you will get used to it quickly. Thanks to this pattern it's very hard to ignore errors. The only think that could be done better is instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace: E.g: - task failed because - authentication failed because - could not load credentials because - because file xy.pem is not readable But instead of the above, you often just receive a "permission error", but you don't know where it came from, which can make debugging hard. Edit: formatting
- jsk2600 10y ago
  Thank you ! >instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace Isn't that basically just reinventing exceptions, sort-of ?
  - sly010 10y ago
    Basically. It's a little different because you have more control. It's way too easy to assume exceptions won't happen and basically ignore them. But they happen in unexpected places (e.g. every time when dealing with IO). Exceptions only contain a function call trace (stack of function calls), while a logical error trace is more like an explicit try/catch/wrap/throw around every call and could be more informative to the end user if done properly.
  - supremesaboteur 10y ago
    This does not require exceptions. A very simple implementation could involve appending the additional error to the messsage from the lower error level. As far as I understand, exceptions were invented so that error handling code will not clutter up the "happy path". They allow "exceptional condition handling" to be seggregated. But in real world applications you may need to, say, recover from an error. For example, if connection using https fails, fallback to http. This makes code using exceptions look wonky. So might as well use error codes always
the_duke 10y ago
It's the bane of Go code. If you want to write it safely, you will have `if err != nil` everywhere. This is normal and expected.
codemac 10y ago
Unfortunately, yes. The best phrasing I've heard recently is "Go is useful drudgery".
fancy_pantser 10y ago
This particular code would benefit greatly from named return values. For example, BuildStats is defined as returning (* stats, int, error), when it could name those and just use naked returns. In buildInstancesStats, they name the return values but then repeat them again on all 3 return lines instead of just using a naked "return". Quick intro form the tour with a good example: https://tour.golang.org/basics/7 https://tour.golang.org/basics/7
deleted 10y ago
[deleted]

by jsk2600 10y ago

spullara 10y ago

That is actually how you do error handling in go. Just awful IMHO.

sly010 10y ago

It's pretty normal and you will get used to it quickly. Thanks to this pattern it's very hard to ignore errors. The only think that could be done better is instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace: E.g: - task failed because - authentication failed because - could not load credentials because - because file xy.pem is not readable But instead of the above, you often just receive a "permission error", but you don't know where it came from, which can make debugging hard. Edit: formatting

jsk2600 10y ago
Thank you ! >instead of always blindly returning an error, one could wrap them in higher level errors and build a sort of error trace Isn't that basically just reinventing exceptions, sort-of ?
- sly010 10y ago
  Basically. It's a little different because you have more control. It's way too easy to assume exceptions won't happen and basically ignore them. But they happen in unexpected places (e.g. every time when dealing with IO). Exceptions only contain a function call trace (stack of function calls), while a logical error trace is more like an explicit try/catch/wrap/throw around every call and could be more informative to the end user if done properly.
- supremesaboteur 10y ago
  This does not require exceptions. A very simple implementation could involve appending the additional error to the messsage from the lower error level. As far as I understand, exceptions were invented so that error handling code will not clutter up the "happy path". They allow "exceptional condition handling" to be seggregated. But in real world applications you may need to, say, recover from an error. For example, if connection using https fails, fallback to http. This makes code using exceptions look wonky. So might as well use error codes always

the_duke 10y ago

It's the bane of Go code. If you want to write it safely, you will have `if err != nil` everywhere. This is normal and expected.

codemac 10y ago

Unfortunately, yes. The best phrasing I've heard recently is "Go is useful drudgery".

fancy_pantser 10y ago

This particular code would benefit greatly from named return values. For example, BuildStats is defined as returning (* stats, int, error), when it could name those and just use naked returns. In buildInstancesStats, they name the return values but then repeat them again on all 3 return lines instead of just using a naked "return". Quick intro form the tour with a good example: https://tour.golang.org/basics/7 https://tour.golang.org/basics/7

deleted 10y ago

[deleted]