[GitHub] [trafficcontrol] zrhoffman commented on pull request #5162: Traffic Ops API Errors structure

[GitBox <gi...@apache.org>]

zrhoffman commented on pull request #5162:
URL: https://github.com/apache/trafficcontrol/pull/5162#issuecomment-710670282


   > > > the (error, error, int) and (int, error, error)
   > > 
   > > That was my mistake, and I apologize. IMO the idiom should always be "userErr, sysErr, errCode". The funcs that got it backward are my fault, and should be fixed.
   > 
   > Are you sure? The Go standard library always returns errors last in multi-value returns, and go-lint's default ruleset would have a problem with all of our call signatures if they didn't conform to that convention. If we wind up not making any new structure at all, to be honest I'd prefer "errCode, userErr, sysErr".
   
   As I [said in #5071](https://github.com/apache/trafficcontrol/pull/5071#discussion_r501175965), I think `(error, error, int)` should be exempt from that rule because an HTTP status code is effectively an error code.
   
   Golint rules exist to guide developers for whom conventions would otherwise be arbitrary. We have a good reason not to do it that way, so we should do it our way in this case.
   
   All we need to do for `golangci-lint` to ignore that particular `golint` rule is to add it to `issues.exclude-rules` in our `.golangci.yml`. We could also go a step further and enforce `errCode, userErr, sysErr` in our linting.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org