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

Remove the 'error' case from the 'GRPCClientResponsePart' #1035

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented Nov 5, 2020

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.
@glbrntt
Copy link
Collaborator Author

glbrntt commented Nov 5, 2020

cc @PeterAdams-A @Davidde94

@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Nov 5, 2020
Copy link
Contributor

@Davidde94 Davidde94 left a 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?

@glbrntt
Copy link
Collaborator Author

glbrntt commented Nov 5, 2020

LGTM, but wouldn't have using Result<Error, Success> saved you some effort?

How do you mean?

Copy link
Contributor

@PeterAdams-A PeterAdams-A left a 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?

@glbrntt
Copy link
Collaborator Author

glbrntt commented Nov 6, 2020

@PeterAdams-A we don't have allocation counting tests yet

@Davidde94
Copy link
Contributor

@glbrntt onResult: (Result<Error, SuccessType>) -> Void. Anyway, just a thought, the code looks good

@glbrntt
Copy link
Collaborator Author

glbrntt commented Nov 6, 2020

@glbrntt onResult: (Result<Error, SuccessType>) -> Void. Anyway, just a thought, the code looks good

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!

Copy link
Contributor

@PeterAdams-A PeterAdams-A left a 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.

@glbrntt glbrntt merged commit 605a679 into grpc:gb-feature-interceptors Nov 6, 2020
@glbrntt glbrntt deleted the gb-interceptors-client-request-part branch November 6, 2020 13:59
glbrntt added a commit that referenced this pull request Nov 6, 2020
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.
glbrntt added a commit that referenced this pull request Nov 12, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants