Skip to content

Support for framework exceptions #295

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

Merged
merged 2 commits into from
Mar 29, 2021
Merged

Conversation

adamthom-amzn
Copy link
Contributor

Description of changes:

The most controversial part of this, I expect, will be the hand-built static model for these that I use to reuse the code generators. I wonder if I should replace the context's SymbolProvider as well, in the event one of the error serialization implementations tries to do a symbol lookup. I didn't go to those lengths in this review because I'm unsure framework errors will ever be much more than a name, a status code and a message.

In the future, if we allow customization of the namespace of the framework exceptions for backwards compatibility with existing services, the static model will have to turn into a model factory of some sort.

You can take a look at the generation changes here: https://github.com/adamthom-amzn/smithy-typescript-ssdk-demo/commit/503b7ae1be16113be2fbcc1cf8af3d1ded01cbb9 and the TS definitions of the framework exceptions here: https://github.com/adamthom-amzn/smithy-typescript-ssdk-demo/commit/64ec3c51f7e0583eed61770d15c8479d4b1949ce

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

*
* @param serverContext Serialization context.
*/
void generateFrameworkExceptionSerializer(GenerationContext serverContext);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the term "Error" in other interfaces so we should here as well for consistency

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually halfway to changing Exception to Error globally in my review yesterday before submitting it but then I saw how often I was handling SmithyException and SerializationException and UnknownOperationException and I left it. I can change the method names in the generator for sure.

@adamthom-amzn adamthom-amzn force-pushed the ssdk branch 2 times, most recently from daf42da to 55860c4 Compare March 25, 2021 18:06
Framework exceptions are ones that are not modeled by the service owner and
will never be expected to have specific types generated by any client. They are
not framework errors simply because they are ubiquitous, but because we have to
be able to throw them regardless of the service model. They should represent
the inability for the framework to process the request, as opposed to the
framework refusing to process the request.
@JordonPhillips JordonPhillips merged commit 257d395 into smithy-lang:ssdk Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants