+1 for this idea. I like the idea of a package that holds error codes. Regarding error codes type, I don¹t have a strong opinion. My preference would be enums because my IDE can help me and the compiler can help a bit.
Paul On 9/11/16, 10:44 AM, "Sterling Hughes" <[email protected]> wrote: >PS: I wonder if we shouldn¹t create a package (sys/error) that >everything in the system relies upon, that provides standardized error >codes for the system. > >On 11 Sep 2016, at 10:42, Sterling Hughes wrote: > >> Hey, >> >> Across the OS, we have two interfaces: some that use os_error_t, and >> the other that uses int¹s for return codes. >> >> Personally, I have never liked using a typedef for an error code >> (largely as a short hand for an enum.) I like to have a single >> variable ³rc² that I use for error accounting ‹ which works fine >> with enums, but if the type changes under me, then all the code >> doesn¹t compile. Plus, there are cases where I want to return >> values and error codes in a single int (positive = val, negative = >> error code.) In order to stick with the spirit of an enum, I¹d have >> to separate the value and return code, and I¹m lazy and dislike >> functions with unnecessarily long signatures. >> >> And ³os_error_t² only applies to OS error codes, and our libraries >> are mixed. FS uses Œ#defines¹, whereas BLE uses enums again. >> >> So ‹ prior to 1.0, I think we should clean this up. My proposal is >> to go with plain old integers as error codes across the system. 0 is >> no error, a negative value is the error code and a positive value can >> be used when returning actual data (and must be marked in the function >> signature/doxygen comment.) Although, if we want to go the enum >> route, I¹m happy with that too, but I think we should clean up the >> code that currently uses integers as return values (there is a lot of >> it), to move to cleanly specifying where the error parameters are. >> >> Sterling
