What I was thinking of was something short and high level, added as a section to https://grpc.io/docs/guides/error/ to 1) make users aware that it's not just them that's thinking "wow, gRPC's error model is REALLY limited, how am I going to ...", and 2) mentioning some approaches that have been used to address this.
I'd be happy to take a stab at it and submit a PR, but something like this: *Options for Implementing Richer Error Models* The error model described above is the only official gRPC error model and is supported by all gRPC client/server libraries and is independent of the gRPC data format (whether protocol buffers or something else). As such it is necessarily very limited and lacks the ability to communicate error details in a standard way. If you're using protocol buffers as your data format, however, many of the gRPC libraries now support the richer error model developed and used by Google as described here <https://cloud.google.com/apis/design/errors>. If you're not using protocol buffers, but do want to continue supporting the standard over-the-wire gRPC error model, you could similarly use gRPC response metadata to convey error details by documenting your representation model and optionally creating helper libraries to augment the gRPC libraries and assist with producing and consuming the error details. Some things to be aware of if you adopt such an extended error model, however are ... On Thu, May 30, 2019 at 10:17 AM 'Carl Mastrangelo' via grpc.io < [email protected]> wrote: > Because writing good documentation is time-consuming :) At the time I > joined the gRPC team, there was an HTTP RFC in the works for standardizing > on a JSON error format (it didn't pan out). Some of the original authors > were exploring using it, and defining conversions between Googles own types > and the "standard"-to-be. > > I wouldn't mind publishing *my* experience error handling (and I do have a > lot), but it's a higher bar to speak on behalf of the rest of the team. > There are some big issues that have answers that go either way: > > 1. Should gRPC use HTTP error codes in addition to the one from the > status? Some of them seem easy enough to write (UNIMPLEMENTED -> 404). > Some are more difficult (UNKNOWN -> ?? 500? ) > 2. What should happen with packed error values in google.rpc.Status? > Should they be expanded into HTTP fields? Should they remain in the > proto so processors can skip parsing? > > Those are the two I know of of the top of my head, and there's a bunch of > sub problems in that space that you can see gRPC *did* take a stance on > (like inner error codes and messages matching the encapsulating message's > error codes). Reasonable people could go either way on several of these > issues, and different environments will bias people's answers. (If you > work in Go exclusively, you might think stack traces in errors are > wasteful, if you work in Java, you might be more accepting). > > > I am not sure this stuff answers your question. I really wish the gRPC > had a mini design series talking about the technical decisions we have made > over the years. But as I started with: writing takes time. > > > On Wednesday, May 29, 2019 at 9:57:39 PM UTC-7, Chris Toomey wrote: >> >> Why the reluctance to publish guidance on this key aspect of gRPC API >> design? >> >> Has anybody besides Google built a gRPC/protobuf API that provides rich >> error reporting? How did you implement it, and would you have benefitted >> from some published guidance when you started? >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/grpc-io/p_gCk1bn2JE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/f36ae8f4-a934-41bd-89f9-552445c41093%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/f36ae8f4-a934-41bd-89f9-552445c41093%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAGZtczHtD0bzTzMDe5N3WMm3TEbDKH%3D3888DH4F9BRO5n41guA%40mail.gmail.com.
