Riot: [RFC] Definition of error codes returned from driver functions

[gschorcht]

Description

Very often, driver functions return error codes that can be checked by the application to deal with errors.

Question

Which of the following approaches is the best way to define and deal with error codes that are returned from driver functions:

1. Define positive ERROR_CODES and retrurn -ERROR_CODE.
2. Define negative ERROR_CODES and return simply ERROR_CODE.

Approach 1 follows the UNIX style, but is error prone and the application must take into account that the negative values of the error codes have to be checked.

Approach 2 has the advantage that the error codes can be used directly in driver functions as well as by the application.

Personally, I prefer approach 1 despite the disadvantages.

Problem

While searching through the driver implementations, I found both approaches. Maybe there should be defined a design rule that specifies an approach so that all drivers use the same approach.

[dylad]

My personal taste goes for 1.
Should we also consider using errno everywhere to handle error code ? (like the I2C API)

[MrKevinWeiss]

Yup, UNIX style + errno gets my vote!

[kaspar030]

Yup, UNIX style + errno gets my vote!

+1, as long as "errno" means just using the error defines from errno.h, not using the errno variable!

[kaspar030]

using errno everywhere to handle error code ?

I think we should not be dogmatic on this. This should be phrased as "try using errno error codes", maybe not mixing them with custom ones. If there's a case where errnos just don't fit, it is acceptable to have custom error codes.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[gschorcht]

The agreement was to use UNIX style error codes, that is negative values. Should we document it anywhere?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.