Предложение по именованию для перечислений кодов ошибок - PullRequest
Новая
       14

Предложение по именованию для перечислений кодов ошибок

10 голосов
/ 09 июня 2011

Я пишу простой парсер для чтения файла конфигурации. В интерфейсе config.h всего три Основные функции они кратко изложены следующим образом, 

config_init();
config_dinit();
config_parse();
config_read_value();

У меня вопрос: эти функции будут выдавать ошибки различного типа, например, 

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.

Некоторые значения перечисления накладываются друг на друга и также нажимают «ошибка компилятора». лайк OVERFLOW_ERROR,

Я открываюсь для ваших предложений,

и я быстро исследовал Google и обнаружил, что самый популярный клиент IRC исходный код определил перечисления как это, 

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 */
};

он определяет enum без имени, это хороший стиль? Тогда почему, почему тот?

Серьезно нужны более удачные решения по именованию. Пожалуйста, не делай мне больно, я только начните читать книгу «Написание красивого кода на С».

Заранее спасибо. Sandun.

Ответы [ 3 ]

22 голосов
/ 09 июня 2011

Я обычно фанат одного набора возвратов ошибок для всей библиотеки.Таким образом, у потребителей им не нужно беспокоиться о том, что "был -1 плохой вход для X или не мог подключиться к Y" .

Я также фанат E_ префиксы, но на самом деле подойдут любые: 

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 голосов
/ 09 июня 2011

Префикс CMDERR_ в исходном коде клиента IRC является хорошим стилем, но , определяющий enum без имени, не является хорошим стилем .Не хорошо, потому что вы не можете сказать, что это тип enum, только целочисленный тип, как показано ниже: 

CMDERR function1();

int function1(); // actually returning CMDERR unnamed enum

, и вы не можете определить переменную, используя тип enum, как показано ниже: 

CMDERR errResult;

int errResult; // actually errResult is CMDERR unnamed enum
2 голосов
/ 09 июня 2011

Я считаю, что это хороший стиль. Префикс CMDERR_ группирует связанные коды ошибок (при условии, что они связаны с каким-то «вызовом / выполнением команды»)

Поскольку все ваши примеры, похоже, связаны с вашими функциями конфигурации, я бы просто использовал одно перечисление с префиксом CONFIG_ (или CFG_ для краткости). 

enum Config_Errors {
    CONFIG_FILE_NOT_FOUND,
    CONFIG_FILE_EOF_ERROR,
    CONFIG_FILE_OPEN_ERROR,
    //etc.
};

Причина общего префикса заключается в том, что при использовании перечислимого типа вы хотите прояснить, что все члены этого типа принадлежат к одной группе.

...