-
Notifications
You must be signed in to change notification settings - Fork 226
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 errors
to service shape
#894
Labels
feature-request
A feature should be added or improved.
Comments
I've actually implemented that in my protocol, as in, my protocol trait has a field to reference common errors within a service. It implies some pre-processing to forward the errors from the service to the operations, but having it out of the box would be great. |
mtdowling
added a commit
that referenced
this issue
Sep 24, 2021
This commit allows a common list of errors to be bound to a service shape so that every operation within the closure of the service implicitly can return the common errors. This is a very common pattern, and this change makes it easier to add common errors without needing things like validation to enforce them being added to every operation. Existing code generation tooling will either need to be updated to perform a model transform that copies common errors onto each operation bound within a service (see `copyServiceErrorsToOperations`), or they need to use the introduced `getErrors` method on `OperationIndex` that also takes in a service shape ID. Closes #894
mtdowling
added a commit
that referenced
this issue
Sep 24, 2021
This commit allows a common list of errors to be bound to a service shape so that every operation within the closure of the service implicitly can return the common errors. This is a very common pattern, and this change makes it easier to add common errors without needing things like validation to enforce them being added to every operation. Existing code generation tooling will either need to be updated to perform a model transform that copies common errors onto each operation bound within a service (see `copyServiceErrorsToOperations`), or they need to use the introduced `getErrors` method on `OperationIndex` that also takes in a service shape ID. Closes #894
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's a common pattern in APIs to support a set of errors across all operations. An
errors
property could be added to theservice
shape to add a list of errors to every operation within the closure of the service.The text was updated successfully, but these errors were encountered: