항목 18에서 얼마나 많은 예외가 발생할 수 있는지 알아 보았다면, 이번 항목에서는 어떻게 하면 그런 예외들을 잡을 수 있을까? 에 대한 고민을 하게 해 준다.


예제 코드


우선 이 함수가 어떤 예외 안전성을 가지고 있나?

예외 안전성에는 1. 기본 보증(객체 상태를 변경시키지 않는다), 2. 강한 보증(프로그램 상태가 바뀌지 않는다), 3. 완벽한 보증(예외를 절대 발생시키지 않겠다!) 로 나뉠 수 있다.

기본 전제로 EvaluateSalaryAndReturnName 내부에서 호출 된 함수들은 강한 예외 안전성을 가지고 있으며, 임시 객체를 포함한 사용된 어떤 개체에서든지 예외에 안전하다는 전제를 둔다.


해설

해당 함수는 기본적으로 Employee e 상태를 변경 시키지 않기 때문에, 기본 보증을 하고 있다. 또한 18항목에서 보았듯이 무수히 많은 예외들이 위의 전제로 다 사라지고 두가지의 예외에 대해서만 초점을 맞추게 된다.

아참, 우선 스트림 출력에 있어서의 예외는 무시해야 한다. 뒤에 설명하겠지만 스트림 출력의 경우 메세지를 출력했는데, 예외를 발생 시킬 수 있다;

1. 메세지 취합 과정에서의 예외(" is overpaid" 생성 시)

2. 리턴되는 값에 대해서의 예외( return e.First() + " " + e.Last( ) 경우 )


첫번째의 경우, cout 으로 다른것들이 스트림을 통해서 출력되었는데, is overpaid 생성시 예외 발생되면, 함수에서 빠저나가게 되면서, .. 화면에는 출력된 어처구니 없는 상황에 직면하게 된다.

두번째의 경우, 모든 일을 다 처리 했는데, return 과정 중 예외가 발생해서, 모든 작업이 .. 날라가는 어처구니 없는 경우를 맛보게 된다.


이런 두 종류의 예외를 한 함수에 가지고 있으면, 일반적으로 하나씩 예외에 안전하게 짜거나, 한 종류의 예외 발생가능성 부분을 함수로 빼어, 예외의 종류를 분리시키는 방법을 쓴다.(. 예외에 안전하게 짜려 한다면)

우선 메세지 취합 과정에서의 예외 부터 해결하자.

첫번째 문제 해결 코드

첫번째 경우, 취합과정에서 예외가 발생할 경우 그 전에 cout 한것을 주울수 없는 문제를, 우선 모두 취합한 후에 cout << message 를 한 것을 볼 수 있다. 이것으로 첫번재 문제는 해결 되어 졌다.


두번째 경우, 리턴 값을 .. 문장이 길어지니 항목 37 : AUTO_PTR[각주:1] 로 대체 한다. 여담으로, 이렇게 블로그에 글을 남기는것도 어찌보면 .. 이전글이라는 함수 호출 : )


마지막으로 스트림에 대한 이야기를 하자면, 스트림이라는 것이 한번 밖으로 나간것은 되돌릴 수 없기 때문에, 표준 스트림에 있어선 절대로 강한 예외 안전성을 보장 할 수가 없다. .. 이미 모니터에 출력되었는데, 뒤로 가서 지울 수 없듯이, 스트림 사용에 있어서 좀 생각해 봐야 할 것이다.


총평

한참 동안 반복해서 읽었다. 이것으로 몇가지 사실을 알았는데, 만약 예외에 대해서 기본 보증 말고 강한 보증이나 완벽 보증을 하고 싶다면, 각 예외의 종류를 나누어 처리되는 함수를 만드는게 제일 편하다고 생각 한다.

여러가지 장점이 있겠지만, 예외에 안전하다고 해서 좋은것만은 아닐 것이다. 왜냐하면 거기에 합당한 비용을 지불해야지만 되기 때문이다. 기본 보증도 훌륭하다고 생각하다는것은 나만의 생각 일까?


  1. http://www.ikpil.com/667 [본문으로]
  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기