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

Add SPIs for throwing RuntimeError from shorthand generated APIs #56

Merged
merged 3 commits into from
Oct 3, 2023

Conversation

simonjbeaumont
Copy link
Collaborator

@simonjbeaumont simonjbeaumont commented Oct 2, 2023

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

  • Extend internal enum RuntimeError: Error with two new cases:
    • .unexpectedResponseStatus(expectedStatus:response:)
    • .unexpectedResponseBody(expectedContent:body:)
  • Add SPI for generated code, to throw these errors:
    • @_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

  1. https://github.com/apple/swift-openapi-generator/pull/291

Copy link
Contributor

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

Sources/OpenAPIRuntime/Errors/RuntimeError.swift Outdated Show resolved Hide resolved
@_spi(Generated)
public func throwUnexpectedResponseBody(expectedContent: String, body: Any) throws -> Never {
throw RuntimeError.unexpectedResponseBody(expectedContent: expectedContent, body: body)
}
Copy link
Contributor

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).

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

@simonjbeaumont
Copy link
Collaborator Author

@swift-server-bot test this please

1 similar comment
@simonjbeaumont
Copy link
Collaborator Author

@swift-server-bot test this please

@simonjbeaumont simonjbeaumont marked this pull request as ready for review October 3, 2023 06:19
@simonjbeaumont
Copy link
Collaborator Author

Merging over broken integration test, which is failing because we haven't tagged a 0.3.0 for swift-openapi-generator yet.

@simonjbeaumont simonjbeaumont merged commit 0030548 into apple:main Oct 3, 2023
@simonjbeaumont simonjbeaumont added the 🔨 semver/patch No public API change. label Oct 3, 2023
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.

2 participants