"what's the general consensus..." <- > <@rursprung:matrix.org> what's the general consensus / recommendation on how to deal with `Result` returned from a-h APIs in driver crates? > previously my driver didn't need to bother with this as the `OutputPin` APIs were infallible, but this has now changed. in the initial migration step i just silently `unwrap`ped it, but the proposal from @ripytide is now to propagate them upwards for the rare case that a HAL impl might not be infallible. the change would add quite a bit of error-enum handling to the code: https://github.com/rust-embedded-community/tb6612fng-rs/pull/37 > > i'm ok with adding this, but was wondering what others have done when they updated to e-h 1.0 (or RC.3)? enum Errors are nice for debugging and you can choose what to do with different kinds of errors. A balance has to be found on what is too much information. If something fails in rtic init it is probably fine with unwrap as you can't recover from that. Looking at DriveError from the code it looks to me like there is too much information to bubble up. Do you need to know why it could not set the pin or is `Result<(),()>` enough. I have not found any clear cut rules for what is good enough but it gets messy fast if you want every error type to be available on the surface