PR would be great. I would be happy to do review, and find some other people to look as well.
On Thursday, May 30, 2019 at 7:57:44 PM UTC-7, Chris Toomey wrote: > > 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] <javascript:>> 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] <javascript:>. >> 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/1163311e-e6fc-4282-af7f-fe967eec347a%40googlegroups.com.
