{
이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다.

이것이 왜 중요한가?
 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다.

책에서는 모라고 하는가?
 개발 초기에 먼저 정하고 개발하라고 한다.

어떻게 정하는가?
 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다.

그리고 오류의 수준을 정한다. babo_num > 30 이면 최강 오류다. 라는 식인데, 우리 프로젝트에선 오류의 수준을 FATAL, ERROR, WARN 등으로 나눈다.

그리고 오류를 보고 하는데, 보통 파일로 남기거나, DB에 밀어 넣는다.  언제 어디서 어떻게 났는지를 말이다.

그리고 오류를 처리 한다. FATAL 이면 프로그램 종료 ERROR 면 예외처리 WARN 이면 경고.. 식으로 수준에 맞게 처리 한다.

마지막으로 책에선 오류를 전달한다면, 어떻게 전달할지를 정하라고 한다. 예를 들어 C API 에 오류를 전달하고자 한다면 catch(...) 를 사용하라고 가변인자 함수를 만들어서 거기로 넘기라는 것인가? 크... 모르겠다.

분명한건 오류라는 입력을 연산하여 출력 하는 과정을 확실히 명시하라는 이야기이다.

}

저작자 표시
신고

'책 정리 > C++ Coding Standards : C++ 코딩의 정석' 카테고리의 다른 글

항목 74 : 목적에 맞게 오류를 보고하고, 제어하고, 변환하라. ( eport, handle, and translate errors appropriately. )  (0) 2009.05.02
항목 73 : 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라. ( Throw by value, catch by reference. )  (0) 2009.05.02
항목 72 : 오류 보고에는 예외를 활용하라. ( Prefer to use exceptions to report errors. )  (0) 2009.05.02
항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라. ( Design and write error-safe code. )  (0) 2009.04.29
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. )  (0) 2009.04.28
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. )  (0) 2009.04.17
항목 68 : 내부적인 가정과 규칙을 확실하게 명시하라. ( Assert liberally to document internal assumptions and invariants. )  (0) 2009.04.17
항목 100 : 배열을 다형적으로 다루어서는 안된다. ( Don’t treat arrays polymorphically. )  (0) 2009.04.17
항목 99 : 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라. ( Don’t use invalid objects. Don’t use unsafe functions. )  (0) 2009.04.17
항목 98 : 가변 인자의 사용을 피하라. ( Don’t use varargs (ellipsis). )  (0) 2009.04.17
항목 97 : union 사용을 주의하라. ( Don’t use unions to reinterpret representation. )  (0) 2009.04.17
posted by 농사를 짓는 게임 프로그래머 최익필

댓글을 달아 주세요