-
Notifications
You must be signed in to change notification settings - Fork 46
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
Add SPIs for throwing RuntimeError from shorthand generated APIs #56
Conversation
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.
One nit, one suggestion, otherwise looks good.
@_spi(Generated) | ||
public func throwUnexpectedResponseBody(expectedContent: String, body: Any) throws -> Never { | ||
throw RuntimeError.unexpectedResponseBody(expectedContent: expectedContent, body: body) | ||
} |
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.
I think these could go into ErrorExtensions.swift
, and maybe return the constructed error rather than throw it (similar to DecodingError.failedToDecodeAnySchema(...)
etc).
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.
Happy to explore a better home for these, but is ErrorExtensions.swift
a good fit?
In ErrorExtensions.swift
we extend the public type DecodingError
. Here we are creating an internal RuntimeError
. Had this been a public type, I'd have made these SPIs extensions of RuntimeError
.
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.
True, maybe the whole file should be renamed to ErrorUtilities.swift or something, or a new ErrorFactories.swift file could hold these. Will leave up to you.
Co-authored-by: Honza Dvorsky <[email protected]>
Signed-off-by: Si Beaumont <[email protected]>
ff988e1
to
c39d002
Compare
@swift-server-bot test this please |
1 similar comment
@swift-server-bot test this please |
Merging over broken integration test, which is failing because we haven't tagged a 0.3.0 for swift-openapi-generator yet. |
Motivation
The review period for SOAR-0007 (Shorthand APIs for inputs and outputs) has now concluded. This pull request adds the required SPIs to the runtime library to throw a runtime error when the response and/or body does not match that of the shorthand API being used.
For further context, please review the proposal itself.1
Modifications
internal enum RuntimeError: Error
with two new cases:.unexpectedResponseStatus(expectedStatus:response:)
.unexpectedResponseBody(expectedContent:body:)
@_spi(Generated) public throwUnexpectedResponseStatus(expectedStatus:response:)
@_spi(Generated) public throwUnexpectedResponseBody(expectedStatus:body:)
Result
Runtime library has two SPIs that can be used by the generator to implement the shorthand throwing getter APIs described in SOAR-0007.
Test Plan
Companion PR in swift-openapi-generator.
Footnotes
https://github.com/apple/swift-openapi-generator/pull/291 ↩