Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

embedded_hal errors shouldn't be ignored #34

Closed
ripytide opened this issue Jan 10, 2024 · 1 comment · Fixed by #37
Closed

embedded_hal errors shouldn't be ignored #34

ripytide opened this issue Jan 10, 2024 · 1 comment · Fixed by #37

Comments

@ripytide
Copy link
Collaborator

While I was working on #26 and similar pr's I found it strange that various embedded_hal errors are just ignored rather than being returned to the caller which seems like the idiomatic thing to do since this is a library.
Example:
https://github.com/rursprung/tb6612fng-rs/blob/82c7c815a49a9e40a0853d095dd8371e6267ed69/src/lib.rs#L237-L238

At first I thought those errors would be encapsulated in DriveError but it seems actually that is only for speed errors so maybe it should be renamed SpeedError.

@rursprung
Copy link
Collaborator

you're right, i should've probably propagated this upwards! i think this was just a lazy (late-night?) attempt at quickly porting from e-h 0.2 (which had infallible APIs) to 1.0 (which has the Result but in 99.9% of the cases will still be infallible for these actions).
it'd make sense to propagate these errors up to the caller

ripytide added a commit to ripytide/tb6612fng-rs that referenced this issue Jan 15, 2024
allow clippy lints for type complexity
@ripytide ripytide linked a pull request Mar 3, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants