These are all very good points. I've looked at etcd3 as well as a few other projects using GRPC and they just rely on the GRPC status codes.
I guess the root of the problem is probably the granularity of the GRPC status codes. For example, in the service implementation, I might have multiple errors returned as INVALID_ARGUMENT. However, it is not possible to signal which field is invalid in a given request. I think the only way to do this is to use WithDetails() and the BadRequest protobuf message type. I have decided on the following strategy: - Do not use WithDetails() if possible. - If the client really needs the extra granularity (to implement different behaviors), then use WithDetails(). I think the code is easier to manage this way, however, there's a fair bit of mental overhead/coupling to decide whether the client will require this granularity. In addition, there is still 1 problem I have not successfully solved: For extra granularity, I am returning strings like "EMAIL_ADDRESS_NOT_FOUND" as the BadRequest's Description as part of WithDetails(). However, this requires a fair bit of bookkeeping in the client. For example, there is no way to signal that the string has changed or has been deprecated without a lot of manual documentation. In addition, there is no nice way to guard against typos when using these strings in the clients. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5ba905a4-03c7-40c8-a64f-ee78ec0e5112%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
