Add RFC for Error Context and Compatibility #1819
Conversation
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
| 3. Use of enum tuples, even with `#[non_exhaustive]`, adds friction to evolving the API since the | ||
| tuple members cannot be named. |
There was a problem hiding this comment.
This is suuuuuuuch a good callout and one that didn't even occur to me
| } | ||
| } | ||
|
|
||
| pub struct VariantC { some_private_field: u32 } |
There was a problem hiding this comment.
You know how you can define associated types and consts in traits? It'd be cool if you could define a struct inside an enum without using a struct enum variant, just to show that they're intentionally linked together forever.
There was a problem hiding this comment.
pub enum MyError {
struct A {
some_private_field: String,
}
VariantA(A)
}There was a problem hiding this comment.
That would be nice.
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Overall, I like the direction here. I feel like there are two big pieces missing from the RFC:
- This RFC doesn't ever talk about the experience that customers have actually dealing with these errors or ways we can make the errors easy (or hard) for customers to interact with. I'd love to see code examples that showed what it's like to interact with these errors.
My hope is that by digging into this more directly, we'll be able to settle on a key set of utilities (is_foo() maybe?) that will make errors easy for customers to interact with while maintaining all of our backwards compatibility
2. Other than careful code review, I think we need a mechanism to drive consistency here, otherwise I suspect even after a large effort to remove divergence, things will diverge again.
| In code where errors are logged rather than returned to the customer, the full error source chain | ||
| must be displayed. This will be made easy by placing a `DisplayErrorContext` struct in `aws-smithy-types` that | ||
| is used as a wrapper to get the better error formatting: |
There was a problem hiding this comment.
one thing that I wish we were able to better support was retroactively adding context to an existing error—I feel like that's a very common pattern that would improve the errors we're able to give to customers & reduce the need to get debug logs when resolving issues
Yeah, that wasn't the intent of this RFC, although the The crate organization RFC was originally tackling some of the ergonomics issues, but I've since moved this into a separate RFC.
Yeah, we could consider implementing a special linter for this. It's hard to say if that additional effort would be worth it or not though, unless another tool makes this a lot easier. |
This RFC proposes a pattern for writing Rust errors to provide consistent error context and forwards/backwards compatibility.
Rendered
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.