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
