gRPC error handling best practice

[Sankar]

Hi

This is a question on what is the best practice to handle errors in gRPC. To explain: I have a .proto file with a service API:

service Search {

 rpc Search (Params) returns (Results)

}

where the "Results" could be defined as either:

message Results {

  //int64 errorCode = 1; Should I uncomment this and the next line ??

  //string errorDescription = 2;

  repeated Result result = 3;

}

For the above .proto file, the generated _pb.go file will be like:

Search(ctx context.Context, in *Params, opts ...grpc.CallOption) (*Results, error)

Now there is an 'error' parameter in the API. What is the most recommended procedure to handle our application specific errors ? Should they be part of this "error" parameter or should we add a "error" member inside the "Results" message (uncommenting the lines) and handle outside this second parameter ?

Thanks

Sankar

[Sankar]

Hi

Is there any other mailing list where I should ask such gRPC go related questions ? Any help will be appreciated for the below 'error' question. Thanks.

[Sander van Harmelen]

Hi,

We just use the error parameter as I think that is a much cleaner and more logical approach which is fully inline with any other Go code. This way making gRPC calls is done exactly the same as making any other function or method calls.

Sander

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sankar P]

> We just use the error parameter as I think that is a much cleaner and more
> logical approach which is fully inline with any other Go code. This way
> making gRPC calls is done exactly the same as making any other function or
> method calls.

Is this guaranteed to be similar across all the languages ?

In the .proto file, if we do not add the error also as a message and a
parameter, will codegeneration in every language guarantees that there
will be an error/exception that will be returned as part of each
service ? In languages without multiple return values (say Java), I
suppose that "throws Exception" is more natural and is it guaranteed
to be part of the API generation from the service in the .proto ?

Thanks.

Sankar

--
Sankar P
http://psankar.blogspot.com

[Sander van Harmelen]

Good question… We’re only using gRPC together with Go (at this moment at least), so I don’t have good insights on that one...

Sander

[Sankar]

For any future reference, I have filed this as https://github.com/grpc/grpc-go/issues/646

Thanks.

[Marcus Hines]

Another note you might want to use the grpc canonical error codes to provide the client with more information on the error

Simple example:

import (

"golang.org/x/net/context"

"google.golang.org/grpc"

"google.golang.org/grpc/codes"

        pb "path/to/your/proto"

)

type Service struct {}

func (s *Service) Get(ctx context.Context, in *pb.GetRequest) (*pb.GetResponse, error) {

return nil, grpc.Errorf(codes.Unimplemented, "Currently Unimplemented")

}

Codes provides a list of all canonical codes to use in the return to the client. You can then handle specific error codes based on the type of error returned.  This allows for better specification on your API contract.

[Sankar P]

Thanks. This is very useful. We need more of such tutorials with code
snippets :)