{
개요
 이번 포스팅은 예러를 보고 할 때, 예외:Exception와 에러코드:Error Code 중 예외가 어떻게 더 좋은지에 대해서 정리한 것이다.

본문
에러를 보고 한다는게 무슨 의미인가?
 에러를 보고 한다는 것은 어떤 에러가 났는지 프로그래머에게 알리는 의미를 갖는다.

에러를 보고하는데 어떤 방법이 있는가?
 대표적으로 에러코드(리턴코드)를 이용하여 함수의 리턴값으로 보고하는 형태와 예외(Exception)를 던지는 형태가 있다.

대표적인 이 방법중 무엇이 더 좋은가?
 예외를 던지는 형태가 더 좋다.

왜 더 좋은가?
1. 예외는 무시될 수 없다.
 리턴코드는 리턴에 대해서 처리 하지 않으면, 그냥 무시하고 넘어간다. 결국 이 것을 처리하기 위해선 항상 리턴코드를 제크해야 하는 번거러움이 있다. 하지만 예외는 절대 무시 될 수 없다. 만약 무시한다면, 프로그램을 종료 시켜버리기 때문이다.

2. 예외는 자동으로 전달된다.
 리턴코드는 리턴을 해야지만 밖으로 오류를 전파할 수 있다. 예외는 이러한 전파가 자동으로 처리가 된다. 즉, 직접 예외를 전달할 필요가 없다는 것이다.

3. 예외는 감지와 복구를 손쉽게 작성 할 수 있다.
 리턴코드는 리턴되는 시점에서만 감지 할 수 있다. 그래서 리턴 되는 시점에서만 복구를 할 수 있게 되는데, 이렇게 코드를 구성하게 되면, 감지와 뒷처리가 코드 전체에 덕지 덕지 붙여지고 만다. 이는 가독성이 무척 불편해 지게 되는데, 예외의 경우, 2번에 의해서 감지와 복구를 한곳에서 할 수도 있다.(try catch) 그러므로 덕지 덕지 붙여진 리턴코드 보다 예외가 더 좋다.

4. 예외 처리 방식은 constructors, operators에서 더 좋다.
 리턴코드로는 이러한 생성자나 연산자들에서는 건들 수 없는 영역이다. 하지만 Exception 은 이러한 곳에서도 에러 전파가 가능하다.


성능상에 문제가 많다고 들었다. 정말 인가?
 책의 내용에선 단점이라 볼 수 있는 정도는 아니라고 한다. 한가지 알아 둘 점은 실행파일의 크기를 좀 더 커지게 하는 것인데, 몇몇 컴파일러들은 이 경우 성능에 안 좋은 영향을 미칠 수 있다고 한다.

만약 예외 처리 방식을 지원하는 컴파일러를 사용 하고 있다면, 리턴코드와 예외코드의 성능 차이는 무시될 수 있을 정도로 작다고 한다.(직접 해보는게 좋을 것 같다.) 개인적 생각으론 이건 책의 내용 보다도, 직접 성능 테스트를 해 보는게 좋을 것 같다.


실제로 프로젝트에 사용 해 보았나?
 가끔씩 사용하고 있다. 프로그램을 종료해야 할 정도의 에러의 경우 예외를 던짐으로써 손쉽게 처리 할 수 있는 것을 보았다. 음.. 아직 더 사용해 볼 과제이다.

참고 문헌
CPPCS:항목72, Effective C++, Exceptional C++ Style
}

저작자 표시
신고

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

C++ Coding Standard : 코딩의 정석 목차  (0) 2009.05.04
항목 75 : 예외 명세표는 만들 필요가 없다. ( Avoid exception specifications. )  (0) 2009.05.04
항목 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
posted by 농사를 짓는 게임 프로그래머 최익필

댓글을 달아 주세요