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

guidance on error handling/propagation of drivers #576

Open
rursprung opened this issue Feb 7, 2024 · 3 comments
Open

guidance on error handling/propagation of drivers #576

rursprung opened this issue Feb 7, 2024 · 3 comments

Comments

@rursprung
Copy link
Contributor

since virtually all embedded-hal APIs are fallible (returning a Result) the question has arisen how drivers should return these to the caller when they don't deal with them themselves: should they propagate them upwards 1:1 or should they cover them in a generic "something went wrong" error?
the former has the benefit that the caller of the driver could potentially try to rectify the situation if that were possible (how often is that the case?) but it has the downside of making the API a lot more verbose (presuming that the driver doesn't just have a single e-h error type to propagate up).

a concrete case where this came up is this PR: rust-embedded-community/tb6612fng-rs#37

i think that there should be a general guidance for drivers on how to handle this (what was the reasoning behind the structuring of the errors in the current way?) which should be documented here, centrally.

@Rahix
Copy link

Rahix commented Feb 8, 2024

a generic "something went wrong" error?

As you stated, this can make the API less verbose and will probably be good enough for the vast majority of use-cases. However, I see one major downside: It makes debugging a lot harder because you can no longer just "print the error" in your application to introspect what is going wrong under the hood.

@ryan-summers
Copy link
Contributor

Yes, I have used the approach of mapping all errors into a different "something went wrong" error in the past, and it made things a nightmare in my end application to figure out what was actually happening.

I then immediately refactored my approach to wrapping the e-h Error type into my custom error type so I could propogate it outwards, and I would highly recommend that approach. As @Rahix mentioned, debugging is exceptionally difficult otherwise.

@BartMassey
Copy link
Member

+1 for wrapping. I wish thiserror had a no_std feature. Looks like there's some substitute crates for this, but it would be nicer to bundle it maybe?

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

No branches or pull requests

4 participants