feat: Rust codegen for Errors test model #573
Conversation
|
These things are easier to review if you check in the *.rs files. We can always delete them in a following PR. Along similar lines, maybe this was the PR to delete the *.rs files from Constructor, rather than updating them. I see that the build() functions return aws_smithy_types::error::operation::BuildError, which are then wrapped in an Opaque, and so any actual message is forever lost to the customer. Is there any chance the we could define an additional Error variant for that instead? That said, it's probably best to call this done for now, and make enhancements later. |
Good callout that I think we can address in the scope of supporting Even so, the message isn't actually lost, it's just buried and won't be printed out by default. Do we need to shoot for the display content of any unexpected error being printed when printing an |
|
|
||
| impl ::std::cmp::Eq for Error {} | ||
|
|
||
| impl ::std::fmt::Display for Error { |
There was a problem hiding this comment.
Is this not what #[derive(::std::fmt::Display)] would generate anyway?
| // Using Opaque since we don't have a validation-specific error yet. | ||
| // Operations' models don't declare their own validation error, | ||
| // and smithy-rs seems to not generate a ValidationError case unless there is. | ||
| // Vanilla smithy-rs uses SdkError::construction_failure, but we aren't using SdkError. |
There was a problem hiding this comment.
This comment should probably be a comment on the codegen code instead at this point.
| IOUtils.evalTemplate( | ||
| """ | ||
| $rustErrorName:L { | ||
| message: ::std::string::String, |
There was a problem hiding this comment.
This is fine but reminded me I should cut #575
| @@ -76,10 +76,13 @@ protected Stream<OperationShape> allOperationShapes() { | |||
| } | |||
|
|
|||
| protected Stream<StructureShape> allErrorShapes() { | |||
There was a problem hiding this comment.
FYI for full completeness this needs to also include all errors in any dependent services. But that's not possible to test since we can't build test models with dependencies yet. So this is just fine to hit the bar of supporting the Errors test model in this PR, but we will need to follow up with #576.
Issue #, if available: #534
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.