style: prefer crate-specific error where possible #5631
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
Use a more specific error type.
Why
We have confusing error types that we use in our testing harnesses.
These were then referred to as
crate::testing::Error, etc. This was confusing because you then expect them to be test specific errors but they were just wrapped around standard library types.More specifically, the
Box<dyn std::error::Error>is very rarely necessary in our tests, because everything returns acrate::error::Error. We should prefer to use the more description/specific error type as return values for our tests.How
All tests (except 2) only ever return the crate specific error type. I just used unwraps for the two tests that were working with IO errors.
Testing
Existing CI should pass.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.