-
Notifications
You must be signed in to change notification settings - Fork 76
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
Handling Result
s throughout the crate
#143
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thank you!
I guess this does not need an entry in the changelog if the changes are all internal.
Just out of interest, did you make sure that e.g. the state changes in |
It's hard to say for sure or not because most of the errors would originate in the actual PHY implementation. That being said, I've tested this on both Linux and Windows with an STM32F4 and an H7, and both enumerated properly with both Release and Debug builds. I think most of the racey and/or broken communication issues were control-pipe related and got fixed up in #142 While there's a possibility that issues could be getting introduced, the new logging features should make them simpler to work through when they occur. |
Going to merge this in favor of moving forwards, but will definitely keep an eye out for regressions, thanks for bringing this up @mvirkkunen. |
Fixes #113 by handling all the various
Result<>
types and propogating them upwards topoll()
. For now, they are simply logged. In the future, it could be helpful to push these outwards and havepoll()
return theResult<>
type, however I'm hesitant to introduce a breaking API change right now. I'll spawn an issue for this.This also fixes #58 by propagating the errors described to the new log macros.