问题
I'm writing a simple parser to read the config file.The config.h interface have only three main functions they are in brief as follows,
config_init();
config_dinit();
config_parse();
config_read_value();
My question is those functions will emit different type of errors , for a example,
config_init() emit , FILE_NOT_FOUND,FILE_EOF_ERROR,FILE_OPEN_ERROR, ...
config_dinit() emit , NOT_INIT_ERROR ,
config_parse() emit , PARSE_ERROR, OVERFLOW_ERROR, INVALID_CHARACTER_FOUND_ERROR,...
config_read_value() emit, SECTION_NOT_FOUND,KEYWORD_NOT_FOUND,OVERFLOW_ERROR,NOT_INITIALIZED_ERROR,INVALID_STATE_ERROR,... etc.
Then I create enums for each function, for by using these names ,
enum Config_ParseError{...} , enum Config_InitError{...} ,enum Config_ReadValueError{..}
etc.
Some enum values are overlapping each other and hit "compiler error" too. like OVERFLOW_ERROR,
I'm opening for your suggestions,
and I have done a quick research on the google and found that most popular IRC client source code have defined the enums like this,
enum {
CMDERR_OPTION_UNKNOWN = -3, /* unknown -option */
CMDERR_OPTION_AMBIGUOUS = -2, /* ambiguous -option */
CMDERR_OPTION_ARG_MISSING = -1, /* argument missing for -option */
CMDERR_UNKNOWN, /* unknown command */
CMDERR_AMBIGUOUS, /* ambiguous command */
CMDERR_ERRNO, /* get the error from errno */
CMDERR_NOT_ENOUGH_PARAMS, /* not enough parameters given */
CMDERR_NOT_CONNECTED, /* not connected to server */
CMDERR_NOT_JOINED, /* not joined to any channels in this window */
CMDERR_CHAN_NOT_FOUND, /* channel not found */
CMDERR_CHAN_NOT_SYNCED, /* channel not fully synchronized yet */
CMDERR_ILLEGAL_PROTO, /* requires different chat protocol than the active server */
CMDERR_NOT_GOOD_IDEA, /* not good idea to do, -yes overrides this */
CMDERR_INVALID_TIME, /* invalid time specification */
CMDERR_INVALID_CHARSET, /* invalid charset specification */
CMDERR_EVAL_MAX_RECURSE, /* eval hit recursion limit */
CMDERR_PROGRAM_NOT_FOUND /* program not found */
};
it defines enum without any name, is that a good style?Then why what are the reasons for that?
Seriously need some more good naming decisions. Please don't hurt me I just only start reading "writing beautiful C code" book.
Thanks In Advance. Sandun.
回答1:
I'm usually a fan of one set of error returns for an entire library. This way in consumers they don't have to worry about "was the -1 bad input to X or could not connect to Y".
I'm also a fan of E_
prefixes, but really any will do:
enum _config_error
{
E_SUCCESS = 0,
E_INVALID_INPUT = -1,
E_FILE_NOT_FOUND = -2, /* consider some way of returning the OS error too */
....
};
/* type to provide in your API */
typedef enum _config_error error_t;
/* use this to provide a perror style method to help consumers out */
struct _errordesc {
int code;
char *message;
} errordesc[] = {
{ E_SUCCESS, "No error" },
{ E_INVALID_INPUT, "Invalid input" },
{ E_FILE_NOT_FOUND, "File not found" },
....
};
回答2:
I'm of the opinion that is good style. The CMDERR_ prefix groups together the related error codes (assuming they're related to some kind of "command invocation/execution")
Since all of your examples seem to be related to your config functions, I'd just go with a one enum definition using CONFIG_ prefix (or CFG_ for brevity).
enum Config_Errors {
CONFIG_FILE_NOT_FOUND,
CONFIG_FILE_EOF_ERROR,
CONFIG_FILE_OPEN_ERROR,
//etc.
};
The reasoning behind the common prefix is that when using an enumerated type you want to make it clear that the members of the type all belong to the same group.
回答3:
The CMDERR_
prefix in the IRC client source code is a good style, but defining enum without any name is not a good style. Not good because you cannot say it is an enum type, only an integer type like below:
CMDERR function1();
int function1(); // actually returning CMDERR unnamed enum
and you cannot define variable using the enum type like below:
CMDERR errResult;
int errResult; // actually errResult is CMDERR unnamed enum
来源:https://stackoverflow.com/questions/6286874/c-naming-suggestion-for-error-code-enums