salkinium
commented
7 years ago there is no consistent error handling strategy.
There is now. #185 adds a unified error model to xpcc that works on all platforms (AVR, STM32 and hosted) and does not require use of C++ exceptions. Furthermore it can be used to implement all the behaviors you describe by providing assertion and abandonment handlers. Note that C++ exception cannot be used in xpcc due to them being unavailable on AVRs.
xpcc's error model builds on research by Duffy. The assertion interface is documented here. Also see the examples.
Partially there is no error handling at all.
True. The assertions are pretty new, and I was too busy with modm to actually make use of them ;-P #114 can be immediately fixed now, which I would actually recommend for a more robust use in our robots.
What is the right way to behave for a communication backend on hosted when it encounters an io error?
Assert on it, and it will trigger all assertion handlers and, if they vote for abandonment, also the abandonment handler.
Hi everyone,
I read some of the hosted specific xpcc code and noticed that there is no consistent error handling strategy. Partially there is no error handling at all. Some code just ignores errors and assumes they don't occur, some code prints warnings and continues as if nothing happened, some code can throw exceptions (by using throwing library code), ...
For example, xpcc::hosted::SerialInterface which is used in the CanUSB driver, has a function readBytes that will infinitely loop if the read syscall fails.
xpcc is a microcontroller framework, thus it is not at all reasonable to have any error handling for problems that can't occur on a mcu in its basic interfaces. So we don't have many options. xpcc::Dispatcher for example is a class that is both used on microcontrollers and on hosted. What is the right way to behave for a communication backend on hosted when it encounters an io error?
I can think of three possible behaviours: