It’s a bit of a missed opportunity that gRPC doesn’t formalise the schema of error details like it does for requests and responses. They seemed to have gone the route of leaving it up to service implementors to add error details at their discretion. They’re free to document that these details will be included alongside specific error codes, but this goes against the idea of having a schema at all.
It would’ve been nice to have explicit means of documenting the presence of an error, maybe with different error details for different error codes. Imagine something like the following:
message DoThingRequest { }
message DoThingResponse { }
message TheresNothingLeftToDoErrorDetails { }
message YouHaveNoOneLeftToDoItErrorDetails { }
service MyService {
rpc DoThing(DoThingRequest) returns (DoThingResponse) {
error NOT_FOUND returns (TheresNothingLeftToDoErrorDetails);
error RESOURCE_EXHAUSTED returns (YouHaveNoOneLeftToDoItErrorDetails);
}
}
You get the idea. Each of these error codes declare an error detail that will be included when the specific error code is raised. Not every error code needs to be declared — service unavailable may not have much to say — but if it makes sense for the “business-logic” based error codes to include it, it would be nice to declare this. It could assist users of generated clients, and just be clearer to consumers of the service.
Anyway, just a thought as I battle on with these things myself.