-
Notifications
You must be signed in to change notification settings - Fork 84
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
swift: add response interfaces #261
Conversation
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in #260. Resolves #118. Doc for reference: https://docs.google.com/document/d/1N0ZFJktK8m01uqqgfDRVB9mpC1iEn9dqkQaa_yMn_kE/edit#heading=h.i6ky65xaa9va Signed-off-by: Michael Rebello <[email protected]>
/// Error representing cases when no response was received from the server. | ||
/// I.e., the client went offline or became disconnected. | ||
@objcMembers | ||
public final class NetworkError: NSObject, Swift.Error { |
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.
Hm, more of a platform question:
It is a swift convention to return an error and let the caller handle the error that way, correct?
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.
It is a swift convention to return an error and let the caller handle the error that way, correct?
Are you referring to doing this instead of throw
ing?
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.
Yeah
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.
The benefit of returning an error is that it can be typed. Swift doesn’t allow you to specify which errors can be thrown by a function, so consumers would have to catch all errors and cast. Also throwing wouldn’t work for async
Signed-off-by: Michael Rebello <[email protected]>
Cross-posting from here: This echoes my question on the Request interfaces, but have we thought at all about how might expose response data for streamed processing? This is standard in most HTTP library interfaces, and generally processing/handling of responses tends to be something that can make progress in an online fashion faster than bytes come over the network (i.e. you shouldn't wait to start processing until all bytes have arrived). |
Will comment on that PR so we can discuss, thanks for reviewing! 😄 |
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in #265. Replaces #261. Resolves #118. Signed-off-by: Michael Rebello <[email protected]>
Replaced by: #273 |
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in #265. Replaces #261. Resolves #118. Also resolves #247. Signed-off-by: Michael Rebello <[email protected]>
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in envoyproxy/envoy-mobile#265. Replaces envoyproxy/envoy-mobile#261. Resolves envoyproxy/envoy-mobile#118. Also resolves envoyproxy/envoy-mobile#247. Signed-off-by: Michael Rebello <[email protected]> Signed-off-by: JP Simard <[email protected]>
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in envoyproxy/envoy-mobile#265. Replaces envoyproxy/envoy-mobile#261. Resolves envoyproxy/envoy-mobile#118. Also resolves envoyproxy/envoy-mobile#247. Signed-off-by: Michael Rebello <[email protected]> Signed-off-by: JP Simard <[email protected]>
Adds Swift interfaces for responses within Envoy. These should be at parity with the interfaces being added for Kotlin in #260.
Resolves #118.
Doc for reference: https://docs.google.com/document/d/1N0ZFJktK8m01uqqgfDRVB9mpC1iEn9dqkQaa_yMn_kE/edit#heading=h.i6ky65xaa9va
Signed-off-by: Michael Rebello [email protected]