"a few weeks ago i already..." <- > <@rursprung:matrix.org> a few weeks ago i already asked this here but never got a definitive answer, so here's another attempt: what is the recommended way for drivers to propagate e-h errors to their consumers? should they bubble up each individual error type or should they just wrap it up in a generic "hardware said no" error as the consumer likely anyway can't do anything about it? even more so if it's about GPIO pins which are infallible in 99.x% of the cases. > it's about [this PR](https://github.com/rust-embedded-community/tb6612fng-rs/pull/37) from ripytide which i'd finally like to get merged (either as it is or by adapting it to a single generic error type) > > i think there should be a general guideline/recommendation for this as it affects all `embedded-hal` based drivers. > > (sorry, i had wanted to bring this up in yesterday's meeting but then couldn't make it) FYI: i've now raised an issue for this in hopes of getting an answer: https://github.com/rust-embedded/embedded-hal/issues/576 (also makes the answers better documented)