2 ms·
I still don't see a benefit with this over custom error types. Having a huge switch statement to determine the HTTP response code seems really inefficient vs j
by candiddevmike 4y ago
I still don't see a benefit with this over custom error types. Having a huge switch statement to determine the HTTP response code seems really inefficient vs just doing errors.As and getting the response code directly.
- sidlls 4y agoIt is not efficient, except at that one point in time you write the code. This is `errors.As`: https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/errors/wrap.go;l=78 https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/.... It uses reflection and type assertions and itself contains error checking (e.g. to validate that the arguments are actually error interfaces). It looks efficient in your code because the call is compact, but this is not even close to efficient, and especially not as efficient as a switch statement.
- hellcow 4y agoIt’s very useful when multiple errors happen concurrently, like collecting errors from separate goroutines after they all finish.
- lzap 4y agoGreat example, should have known this one.
- lzap 4y agoAs I said in the article, the example is simplified. As you point out, incorporating the HTTP code into the error and using errors.As is much better way of doing that: "Obviously, the common HTTP status codes could easily be a new error type (based on int type) so the actual code could be easily extracted via errors.As, but I want to keep the example simple."