Better grpc error strings about grpc-gateway HOT 11 CLOSED

It's possible to customize error returns already. Changing the error return structure at this point would break many users. For 2.0 (if that ever comes around) we want to have a serious look at the error returns again. See https://grpc-ecosystem.github.io/grpc-gateway/docs/customizingyourgateway.html.

from grpc-gateway.

+1

from grpc-gateway.

+1

from grpc-gateway.

I don't think it is better to lose error code in the message.
So I still slightly prefer err.Error(). Why do you think grpc.ErrorDesc(err) is better?

from grpc-gateway.

Maybe it is OK to lose error code in the message and make it cleaner. GRPC error code is translated into HTTP status code anyway in the next few line - https://github.com/gengo/grpc-gateway/blob/master/runtime/errors.go#L88 .

from grpc-gateway.

How about this then:

{
  "error": "Unauthenticated",
  "code": 16
}

from grpc-gateway.

@floridoo It is not too bad. But I still don't understand what's wrong in the current format of the message.

from grpc-gateway.

If I understand correctly, what people don't like is that the strings rpc error: code = and desc = are there in every single error message. They're not the actual content, so including them in the output is potentially pointless, it could be considered noise.

I don't feel very strongly about this either way.

from grpc-gateway.

I prefer structured log than combined log because we can take what we want from logs easily.
So +1 to separate to error and code.

from grpc-gateway.

OK. I will accept it if you give me a pull request with the style:

{
  "error": "Unauthenticated",
  "code": 16
}

from grpc-gateway.

Bumping this issue. Is there any way to get the string representation of the code? If exposed to public users, the code doesn't really provide much value. They would have to know to look it up in the codes proto file. Google Cloud for example returns both which is nice. https://cloud.google.com/apis/design/errors#http_mapping

from grpc-gateway.