refactor: use concrete error type #42
Merged
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.
Concrete Error type
Changes the
Esb*traits to require a new traitRadioErrorType.rf24-rs/crates/rf24-rs/src/radio/prelude.rs
Line 457 in da90c7a
In the
RadioErrorTypetrait, there is an associatedErrortype.rf24-rs/crates/rf24-rs/src/radio/prelude.rs
Lines 15 to 18 in da90c7a
Then, the
RadioErrorTypetrait is implemented for theRF24struct.rf24-rs/crates/rf24-rs/src/radio/rf24/mod.rs
Lines 59 to 66 in da90c7a
Subsequent required implementations
The
?operator used to propagateResult::Errneeded an explicit forwarding mechanism for hardware-related errors, namelyembedded_hal::digital::ErrorKind as OutputPinErrorandembedded_hal::spi::ErrorKind as SpiError.rf24-rs/crates/rf24-rs/src/radio/rf24/mod.rs
Lines 47 to 57 in da90c7a
This allows automatic categorization of the error encountered using our
Nrf24Errorenum.Advantages
This convoluted approach
Esb*traits' fallible functions. Previously, each trait had it's own associated error type which didn't bode well for implementing different radio hardware.Using dev branch of embedded-hal-mock fork
There were a few lines about forward error types into our own
Nrf24Errorenum (impl From<T>-- see above).I opened a couple issues to hopefully resolve this upstream in the mock library we're using for unit tests:
with_error()for SPITransactiondbrgn/embedded-hal-mock#128embedded_hal::digital::ErrorKindfor mocked digital pins dbrgn/embedded-hal-mock#129 (would be considered a breaking change though)eh1::digitaluseembedded_hal::digital::ErrorKinddbrgn/embedded-hal-mock#132For now, I'll be using my fork's dev branch until these patches are accepted and deployed upstream.