Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

are all errors returned by gRPC wrapped by status.Status? #1581

Closed
xiang90 opened this issue Oct 16, 2017 · 5 comments · Fixed by #1782
Closed

are all errors returned by gRPC wrapped by status.Status? #1581

xiang90 opened this issue Oct 16, 2017 · 5 comments · Fixed by #1782
Assignees
Labels
P1 Type: Documentation Documentation or examples

Comments

@xiang90
Copy link
Contributor

xiang90 commented Oct 16, 2017

Can I assume that all errors returned by gRPC are https://godoc.org/google.golang.org/grpc/status#Status type?

If so, why ErrClientConnClosing is public? And there are other error types defined in https://godoc.org/google.golang.org/grpc/transport.

@xiang90
Copy link
Contributor Author

xiang90 commented Oct 16, 2017

/cc @gyuho

@gyuho
Copy link
Contributor

gyuho commented Oct 16, 2017

Note: currently we are using grpc v1.6.0. And plan to upgrade to v.1.7.0.

@menghanl
Copy link
Contributor

Status is to represent RPC status (the error code, message and details).
All errors returned by RPCs should be type Status.

Errors returned by other function like Dial are not type Status.

@xiang90
Copy link
Contributor Author

xiang90 commented Oct 16, 2017

@menghanl

Great! That matches my expectation.

Can we document this somewhere? (Or if this is already documented, can you point me to the doc?)

@menghanl
Copy link
Contributor

menghanl commented Oct 16, 2017

It's not explicitly documented now.
In the doc for status package, there's this line that conveys the same message:

gRPC service handlers should return an error created by this package, and 
gRPC clients should expect a corresponding error to be returned from the RPC call

We will see if there's a better place to document this behavior.

@dfawley dfawley added Type: Documentation Documentation or examples P2 labels Oct 17, 2017
@menghanl menghanl self-assigned this Dec 14, 2017
@menghanl menghanl added P1 and removed P2 labels Dec 14, 2017
@lock lock bot locked as resolved and limited conversation to collaborators Sep 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P1 Type: Documentation Documentation or examples
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants