"> <@rursprung:matrix.org> what's..." <- > <@mameluc:matrix.org> 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 thanks for the feedback! yeah, my feeling is also that it's too verbose (that was also my comment on the PR). the counter-statement was > And similar to my comment above there may be scenarios where they need to handle the different types of errors differently and as library authors we should try to make the functionality as flexible as possible so the library can be used for every use-case. what i'm not sure about with the `OutputPin` (and `SetDutyCycle`) errors of e-h: are they supposed to be recoverable? or - besides the 99.x% of all HALs which will just use `Infallible` - will they be fatal errors which you anyway cannot recover from in which case there's no benefit in bubbling up the details to the library consumer and it's ok to just say "computer says no!"?