rob05c edited a comment on pull request #5162: URL: https://github.com/apache/trafficcontrol/pull/5162#issuecomment-712269928
> Are you sure? The Go standard library always returns errors last in multi-value returns Sure. As long as it's consistent, I don't have a strong opinion. I like the code last, but you're right, the error being last is more "idiomatic Go." > No - they do need to both be checked, but I don't need to do it. That's my concern: that nobody will do it, i.e. the `error` will get passed to something that just logs or returns it without doing the type switch, which is always a bug. Likewise, that something will return an `error` that isn't an `APIError` which fails the type switch, also having no correct answer and resulting in a bug. > So call the interface APIError consisting of String() string and StatusCode() int. What's important is that we have a single interface, with two concrete implementations (SysErr and UserErr) To be clear, I'm not opposed to a single return type that implements other interfaces, e.g. `APIErr`, or `SysErr` and `UserErr`. I just think if that type happens to implement `error` it'll be prone to bugs. Anyway, I changed my mind, changing my vote: `+0` on any single return that doesn't implement `error`. I'm not convinced it's better, but I'm open to seeing what it looks like. `-0` on any single return that implements `error`. I still think it's dangerous and prone to bugs, but if everyone else agrees with it, I'm not going to be a binding vote against. ---------------------------------------------------------------- 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: [email protected]
