feat: Simplify StatusTracker interface
#937
Conversation
Having `StatusTracker` as a non-object-safe trait made it impossible to use in further trait APIs. See early draft of #936 for an example of this problem. This PR changes `StatusTracker` to use an enum to describe the only two implementations of `StatusTracker` that have ever existed.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #937 +/- ##
=======================================
Coverage 78.78% 78.78%
=======================================
Files 148 146 -2
Lines 35085 35096 +11
=======================================
+ Hits 27643 27652 +9
- Misses 7442 7444 +2 ☔ View full report in Codecov by Sentry. |
# Conflicts: # sdk/src/asset_handlers/bmff_io.rs
| /// | ||
| /// Primarily intended for use by [`LogItem::success()`] | ||
| /// or [`LogItem::informational()`]. | ||
| pub fn add_non_error(&mut self, mut log_item: LogItem) { |
There was a problem hiding this comment.
Given that LogItem now contains a kind field, there's no need for separate add_non_error and add_error. We should have an add() method that does the right thing. If we aren't ready to update all the calling code, the add_non_error and add_error should simply call add().
There was a problem hiding this comment.
This is carried over from the existing APIs. The primary difference is that add_error can trigger an Err result if the status tracker is configured to stop on first error and in that case, we need to have an Error type ready to use.
The add_non_error case has no return value, so we don't need to pass in an Error.
Having
StatusTrackeras a non-object-safe trait made it impossible to use in further trait APIs.See early draft of #936 for an example of this problem.
This PR changes
StatusTrackerto be astruct. It uses a newenum ErrorBehaviorto describe the only two implementations ofStatusTrackerthat have ever existed.