Better grpc error strings

[floridoo]

Errors currently look similar to this:

{
  "error": "rpc error: code = 16 desc = \"Unauthenticated\""
}

Wouldn't it be better to set error just to the description?

Example:

{
  "error": "Unauthenticated"
}

This can easily be achieved by replacing err.Error() with grpc.ErrorDesc(err) on this line:
https://github.com/gengo/grpc-gateway/blob/master/runtime/errors.go#L77

I can send a pull request if wished.

[pgracio]

+1

[johansja]

+1

[yugui]

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?

[johansja]

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 .

[floridoo]

How about this then:

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

[yugui]

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

[dmitshur]

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.

[kazegusuri]

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.

[yugui]

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

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

[dadgar]

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

[johanbrandhorst]

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.