How to number my Custom errnos

Question

I return a error code if my program was abnormally terminated (via exit()). For standard situations, I just return the underlying errno (for example, ENOMEM for failed mallocs etc). There are, however, also cases when I'll have to terminate due to my own reasons for which there are no system errnos defined.

What error values should I return so that they do not clash with the existing ones. Or am I doing the whole thing assbackwards?

edit: I am sorry if I was not clear with the question. I am not talking about enum etc (they are the mechanism for defining error codes). I was talking of the range of values they could take without clashing with the standard ones.

What I didn't know was that the program can only return 8 bit statuses. So it seems like @r is correct - that is a bit too small to accomodate maybe even all the standard ones, let alone my custom errors. so 1/0 it is :)

Answer 1

The width of the return code is usually pretty small, for example limited to 8 bits, so it's hard to store a lot of information in it. Really I wouldn't bother with exit codes besides 0/1 (success/failure) unless your program is intended for use in shell scripting, in which case you probably just need to figure out the error cases a potential shell script might need to check for and distinguish them (for example, "no match" versus "resource exhausted while searching").

Answer 2

Have you considered using enum to define error codes?

Anyway, here is an interesting discussion about it.

Answer 3

There are few ways to do it.

1) Enums - This can be done in the following way. There is flexibility to add different error codes as and when you need and put them in a group. Say errors related to user authentication, file access, API errors etc.

enum
{
ERROR_GROUP_1 =100,// This gives 99 error codes for a particular group, can be initialised to negative value too.
GROUP1_1,
.
.
ERROR_GROUP_2 = 200
GROUP2_2,
.
.
and so on
};

2) Use pre-processor directives

#define ERROR_CODE_START 00000000L

#define ERROR_CODE_1 (ERROR_CODE_START + 1)

3) Negative return values as int but this will be lot of pain as the reference should be well documented for the values.

4) You can create a structure like GError. Pass a reference to this structure in every API and fill this. If its not NULL then the caller can check the error code and string which will be set in the API.

Answer 4

What error values should I return so that they do not clash with the existing ones. Or am I doing the whole thing assbackwards?

Keep it simple. The most important test for error codes (that is also valid for plain functions) is what the callee can do about it. I have seen projects were people were introducing hundreds/thousands error code for all unique cases what in the end led to the total mess in the error handling (they were trying to give every function/SQL statement a unique exit code). And that - error handling - is precisely the party concerned with the exit codes.

My personal rule for return codes is to make sure that they are useful to the error handling. To exemplify, for a batch program I might have peeked the status codes like that:

• 0 - O.K.,
• 1 - internal but probably recoverable error (e.g. memory allocation error, kill other batches and try to restart),
• 2 - fatal error in config (restart will not help),
• 3 - fatal error in input data (replace input, try again),
• 4 - output got disk full error (clean /tmp, try again).

That is only an example to highlight that the error codes should be thought about from POV of the caller, not callee. If for example, full/partial automation isn't a target and users have to analyze log files anyway, then returning 0 or 1 would also suffice.

Answer 5

On a Posix compliant system, there is absolutely no point in returning any number outside the range 0 to 255. This is because the wait() system call only lets you have the bottom eight bits of the return value of your program (or possibly 16 bits).

In practice, you probably just want a handful of codes, maybe just 0 and 1. Further information can be communicated via stderr in a more useful (to a human) text format.