005 Error codes definition
- Status: accepted
- Deciders: partners
Context and Problem Statement
We need to define a common set of error codes for all API calls to enable better diagnostics in case of runtime errors.
Decision Drivers
- ??
Decision Outcome
Same error type for all methods
Pros and Cons of the Options
Same error type for all methods
e.g.
typedef int SOUTH_API_RESULT;
#define SOUTH_API_SUCCESS 0
#define SOUTH_API_UNKNOWN_VARIABLE 1
#define SOUTH_API_WRONG_ADDRESS 2
- Good, because this is the usual way of defining error codes in C
- Good, because this is directly supported in C
- Bad, because there is no diffentiation between different classes of api functions. Error codes to be expected have to be declared in comments.
One error type for each class of functions
e.g.
enum READ_RESULT
{
READ_RESULT_SUCCESS=0
READ_RESULT_UNKNOWN=1
};
enum WRITE_RESULT
{
WRITE_RESULT_SUCCESS=0
WRITE_RESULT_WRONG_ADDRESS=1
};
enum CONNECT_RESULT
{
CONNECT_RESULT_SUCCESS=0
CONNECT_RESULT_WRONG_ADDRESS=1
};
- Good, because error types to expect are declared expicitely
- Bad, because of very long names due to missing namespace support in C
- Bad, because writing log messages becomes hard
- Bad, because error handling is case to case for each function
One error type for each class of functions but the error codes are the same
e.g.
#define ERR_SUCCESS 0
#define ERR_WRONG_ADDRESS 200
#define ERR_UNKNOWN_VARIABLE 300
enum READ_RESULT
{
READ_RESULT_SUCCESS= ERR_SUCCESS,
READ_RESULT_UNKNOWN=ERR_UNKNOWN_VARIABLE
};
enum WRITE_RESULT
{
WRITE_RESULT_SUCCESS = ERR_SUCCESS,
WRITE_RESULT_WRONG_ADDRESS = ERR_WRONG_ADDRESS
};
enum CONNECT_RESULT
{
CONNECT_RESULT_SUCCESS = ERR_SUCCESS,
CONNECT_RESULT_WRONG_ADDRESS = ERR_WRONG_ADDRESS
};
- Good, because error types to expect are declared explicitly
- Good, because most values can be reused in error handling
- Bad, because of very long names due to missing namespace support in C
- Bad, because compiler does not really enforce the enum range