error value global vs. module specific

 소프트웨어가 커지다 보면, 자연스럽게 OOP개념들을 집어 넣을 수 밖에 없고 - 그렇지 않으면, SW 유지보수가 거의 불가능 하다. - 각 컴포넌트/모듈들을 독립적으로 구현하기 위해서 고민하게 된다.

 각 모듈이나 컴포넌트가 독립적일수록 재사용성이 높아지고 모듈간 의존도가 줄어들게 된다.

 그런데, 문제는 이렇게 서로 독립적으로 만들다 보면, error value들 역시 독립적으로 선언해야 하게 되는데, 이게... 좀... 거시기 하다.

예를 들어, 모듈 A, B, C가 있을 때, A -> B -> C 이런식으로 C가 B를 reference하고, B가 A를 reference하는 경우, C와 B는 각각 내부 구현을 숨기기 위해서, B와 A의 error value를 노출 시킬 수 없게 된다. 따라서, B는 A의 error value를 B자신의 value로 mapping해야 하고, C또한, 이렇게 mapping된 B의 value를 다시 C자신의 value로 mapping해야 하게 된다.

 쩝... overhead의 chain effect라 불릴만 하다.

그래서 많이 하는 방법이, 상당히 자주 사용되는 error value는 global하게 공통적으로 정의하고 - ex. invalid parameter, out of memory 등등 - 세부적인 것들에 대해서는 모듈 specific하게 정의하는 것이다.

예를 들면...

common_error.h

enum {

COMMON_ERR_01 = 0,

COMMON_ERR_02,

...

LIMIT_COMMON_ERR,

CUSTOM_ERR_BASE_OFFSET,

};

module1.h

enum {

MODULE1_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE1_ERR_02,

...

};

module2.h

enum {

MODULE2_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE2_ERR_02,

...

};

 음... 꽤나 괜찮은 해결책으로 보인다. 아니, 현재까지 생각으로는 현실적으로 가장 좋은 해결책으로 보인다.

 그렇지만, 여전히 몇 가지 문제점이 존재한다. 먼저, error value의 return type을 그냥 int 를 사용해야 하는데 - 공통된 error value의 type을 정의할 수 없다 - constant value는 inline으로 코드에 삽입되기 때문에, debugging시에 썩 좋지 못하다는 문제가 있다. 또한, return type이 그냥 int 라 code readability도 썩 좋지 못하다.  또한, global common error code가 module내에서 사용되므로, 이 모듈을 전혀 다른 SW에 porting할때, common error 부분을 해당 SW에 맞게 수정을 가해야 하는 문제도 있다.

 그렇지만, overhead와 재사용성 양쪽을 균형있게 고려한, 충분히 훌륭한 방법임에는 틀림없다.

음...

 혹시 다른 좋은 아이디어가 떠 오르면... 다시 posting하기로 하고...