クラスごとにエラーコードを定義する際の長所と短所は何ですか？

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

クラスごとのエラーコードについて私がコメントしていることの1つは、同じコードが意味するという事実のために（または少なくとも簡単には）単一のエラーロガーを書くことができないということですクラスによって異なるものがあります。

つまり、いつでも両方を使用できます。あなたが持つことができるクラスで、その後

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

と：：

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

グローバルエラーコードのためにあなたに場所を与え、あなたのクラスのエラーコードが重複しないことが保証されます一般的なエラーが発生した世界的な列挙型を持っていますこれはコンパイラによって維持されます。

Answer 2

私はそれがあなたのユーザーにシステムを使いたいかどうかにかかっていると思います。複数のクラスに合ったエラーコードがある場合は、それらを「グローバル」レベルに、組織化された形式（例：コンセプト別に分類されたエラーコード）で配置するのが理にかなっています。クラスがすべて独自のカスタムエラーコードを返す場合は、クラスレベルでさらに定義します。

Answer 3

他のクラスから同じエラーコードが必要な場合は、それらを別々に定義します。ちょっと前に計画を立てる必要があります。今はそれらが必要ではないかもしれませんが、将来同じクラスか同じエラーコードが必要なクラスを作成する可能性があります。

それ以外の場合は、同じクラスにある方がよいでしょう。これは、ソースとエラーコードのメンテナンスに役立ちます。コードを読みやすく理解しやすくなります。

Answer 4

あなたのクラスの外部に存在する意味のある名前付きステータスコードの列挙は良い選択だと思います。このようにして、彼らは彼らの地位の文脈に向かって話します。間違いなく変わるクラスの実装や、複数のクラスにまたがる責任が増大することはありません。

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

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

クラスが液体であまり変化せず、変更される可能性があります。エラーコードを特定のクラスに結び付けることは、明らかな利点がないカップリングのようです。私は（理想的には）状態コードは自分自身に立つことができ、意味を持つことができるはずだと思います。