Каковы плюсы и минусы для определения кодов ошибок для класса?

Question

В процессе создания модуля я сталкиваюсь с дилеммой: должен ли каждый класс внутренне определять свои собственные коды ошибок или должны быть определены коды ошибок для всего модуля?

Пока плюсы и минусы идут рука об руку, но я склонен определять ошибки для каждого класса:

1

class MyClass
{
public:       
   typedef enum _TResult {
       EOk = 0,
       EErrNoMemory,
       EErrBadParam,
       <...>
   } TResult;

   TResult DoSomething();
};

В отличие от чего-то вроде:

2-1

#define OK              (0)
#define ERR_NO_MEMORY   (1)
#define ERR_BAD_PARAM   (2)

Или:

2-2

typedef enum _TResult
{
    EOk,
    EErrNoMemory,
    EErrBadParam,
    <...>
    EErrTimeOut,
    EErrFeedThePenguin
} TResult;

Исходя из вашего опыта, какими будут гоча для любого из подходов?

Answer 1

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

Тем не менее, вы всегда можете использовать оба. Иметь глобальное перечисление с типичными ошибками:

enum GlobalErrors {
   EOk = 0,
   EErrOutOfMemory,
   // etc.
   EFreeErrorCodeBase
};

и затем в классах вы можете иметь:

class Something {
    enum ClassErrors {
       EErrCantInitialize = EFreeErrorCodeBase,
       EErrCorruptedData,
       // etc.
    };
...
};

Что дает вам место для глобальных кодов ошибок и гарантирует, что коды ошибок вашего класса не будут перекрывать глобальные (и это поддерживается компилятором).

Answer 2

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

typedef enum _DatabaseErrorCodes {
   ConnectionFailure = 0,
   Timeout,
   InvalidParameters
} DatabaseErrorCodes;

typedef enum _CommonErrorCodes {
   NullArgument = 0,
   SystemOutOfMemory,
   FeedThePenguin
} CommonErrorCodes;

Классы слишком жидкие и подвержены изменениям. Привязка кодов ошибок к определенному классу выглядит как соединение без какого-либо явного преимущества. Я думаю (в идеале) коды состояния должны быть в состоянии стоять самостоятельно и иметь значение.

Answer 3

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

В противном случае лучше иметь их в одном классе. Это поможет в обслуживании источника и кодов ошибок. Это также облегчит чтение и понимание кода.

Answer 4

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