I think the "right" option is going to depends on your situation and point of view:
*1. This is totally acceptable* To be able to handle errors from Login, I need to understand the application. Therefore, I can't reuse any of the error handling code between this request and other requests, so this seems fine. *2. Use "generic" gRPC codes and status messages* I don't need any specific data back from Login, so I might as well "fail" the gRPC request, and return a gRPC error, since the application will need to handle gRPC errors anyway. As an example, Google Cloud's Spanner API documents their use of the existing gRPC error codes and messages: "Queries inside read-write transactions might return ABORTED. If this occurs, the application should [...]" from https://cloud.google.com/spanner/docs/reference/rpc/google.spanner.v1 *3. Use the google.rpc.Status type* This is sort of a compromise: You still need to know what custom-defined type is in the details field, but the gRPC client libraries provide reasonable support for returning and digging out these errors. For example, in Go: https://godoc.org/google.golang.org/grpc/status Personally, I strive to have my code use option #2, and try not to worry about returning "details." So far we've been able to make this work, but I can see that it won't work in all cases. In that case, I would probably go with #3, since "naive" clients still need to handle those errors, but "sophisticated" clients could do something special. -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/8335b6e3-f02c-46ba-836b-5ffc9ad00d8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
