GRPC transport errors

[kushtrimjunuzi]

There is a situation that I want to retrieve grpc error not fmt.Errorf and looking at the code https://github.com/go-kit/kit/blob/master/transport/grpc/client.go#L93 is returning fmt.Errorf, is there any idiomatic way to retrieve grpc error type when invoking the rpc?

Looking at https://github.com/grpc/grpc-go/blob/master/rpc_util.go#L363 grpc has a method to retrieve error message, we can return an error struct containing grpc error, the struct will be ex.

type rpcError struct{
  rpc error
  err error
}

func(e *rpcError) Error() string{
  return e.err.Error()
}

func (e *rpcError) RPC() error{
  return e.rpc
}

at gokit change will be:

return nil, &rpcError{rpc: err, err: fmt.Errorf("Invoke: %v", err)}
at consumer will be:

type rpcError interface {
  RPC()
}

rpcerr:=err.(rpcError).RPC()
errstr:=grpc.ErrorDesc(rpcerr)

Just an idea, what do you think?

[peterbourgon]

From the Go kit mailing list, I'll copy my email:

We wrap errors in transport/http in a similar way to the proposed, but I'm not convinced it actually brings any value. Does anyone actually switch calling code behavior based on the returned err.Domain? If not, I would vote for removing context altogether, and returning the raw
error. Thoughts?

I didn't get any strong pushback on the thread; any thoughts here?

[basvanbeek]

I have no objection returning the raw errors and haven't noticed any benefits to Domain errors while working with services in production.

[peterbourgon]

Closed with #407!