Posted on June 21, 2016 at 10:20Hello,
while I'm trying to figure out, why a project with USB support is not working as expected, I have to debug a lot in the HAL source code.
Nearly all HAL functions have a HAL_StatusTypeDef as return type. I check the result of such functions with an assert(), as I believe that most function will not return an error, if I used the API correctly or if the function does not run out of resources. All that checking is cumbersome and I wish that the called function would have integrated that assert() for API misuse and other SW developer errors. That would leave the return type only for functions that might fail at runtime even when used correctly.
But instead I find functions that will return always OK or that will simply ignore return values from called functions. So please:
- If there is a function that can not fail, please use void as return type.
- If a function can fail, please document under which circumstances the function will return which error code.
- If a function can only fail if used not correctly (is called with not given precondition, wrong state, wrong parameters), please do the assert() for us and change the return type to void.
- Please, if a called function returns an error, promote that error to the caller and do not simply swallow it.
I know that we all have to work under resource constrains, but every minute saved on HAL code quality will cost your users (costumers) a multitude of that time.
kind regards,
Torsten
#error-handling #hal #code-qualit
