-
Notifications
You must be signed in to change notification settings - Fork 420
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
Remove the 'error' case from the 'GRPCClientResponsePart' #1035
Remove the 'error' case from the 'GRPCClientResponsePart' #1035
Conversation
Motivation: When implementing a bunch of interceptors I found it a little irksome having to deal with errors along with response parts. It feels more natural to deal with them separately. Modifications: - Remove 'error' from 'GRPCClientResponsePart' - Add an 'errorCaught' client interceptor function Result: Errors are handled separately to response parts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but wouldn't have using Result<Error, Success>
saved you some effort?
How do you mean? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tried running this through an allocation test?
@PeterAdams-A we don't have allocation counting tests yet |
@glbrntt |
Oh I see, that becomes a but ugly since the success type is also an enum. It's also against the motivation of the PR! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems ok. I did wonder if a little struct to hold error and response functions might make sense as they keep getting passed about together but no really strong feelings on the matter.
Motivation: When implementing a bunch of interceptors I found it a little irksome having to deal with errors along with response parts. It feels more natural to deal with them separately. Modifications: - Remove 'error' from 'GRPCClientResponsePart' - Add an 'errorCaught' client interceptor function Result: Errors are handled separately to response parts.
Motivation: When implementing a bunch of interceptors I found it a little irksome having to deal with errors along with response parts. It feels more natural to deal with them separately. Modifications: - Remove 'error' from 'GRPCClientResponsePart' - Add an 'errorCaught' client interceptor function Result: Errors are handled separately to response parts.
Motivation:
When implementing a bunch of interceptors I found it a little irksome
having to deal with errors along with response parts. It feels more
natural to deal with them separately.
Modifications:
Result:
Errors are handled separately to response parts.