Open jamesross3 opened 3 years ago
@nmiyake / @tabboud / @bmoylan / @whickman for opinions here
Yeah I would be very supportive of this. The errors coming out of the standard library are almost all well-typed, so this conversion should be relatively straightforward (and can grow over time if we don't hit 100% coverage in the first version).
Definitely agree that this would be a valuable addition!
Similarly, @bmoylan just added a way to identify Timeout errors and tag them in the metrics middleware.
I would be fully supportive of adding a way to wire these errors back through so clients could use something like errors.Is with well defined types.
also interested in whether these error types should affect our existing retry behavior here
There are some error cases for requests where the response is nil; these cases fall outside the scope of the existing error decoder middleware implementation. Examples of errors like this are:
Ideally, CGR provides some methods that enable us to identify these errors (similar to typing conjure errors / attaching status codes to errors)