극강 난이도 9½ 이다. 기본 생성자와 소멸자, 복사 할당자와 복사 생성자를 만들었다면, 이제 스택의 인터페이스를 만들어야 된다. 지금까지 한것들을 간축하게 정리하게 되면

문제 : Count(), Push(), 그리고 Pop()를 예외에 안전하도록 작성해 보도록 하자.

Count( )

이 코드는 예외를 던질 껀덕지도 없다. 패스~

Push( )

이 코드는 보면 NewCopy 에서만 예외를 발생시킨다. 또 v_[vused_] = t; 에서 예외가 발생 시킬 수 있으나, 컨테이너 그 자체를 건들지 않고, 예외 발생시 호출자에게 그 예외를 보고하므로 예외에 안전하다 할 수 있겠다.

가이드 라인
예외를 일으킬 많안 코드를 선택하여 안전하게 옆으로 비껴나갈 수 있도록 만들고, 성공한 사실을 알게 되었을 때(그 밑 라인까지 정상적으로 왔을 경우를 말한다), 실질적인 연산(컨테이너 증가라든지 등등의 정리들)을 시행 하면 된다.

Pop()

이 코드를 보면 4라인, 들은게 없다면 Pop 호출자에게 예외를 던저주고, 그렇지 않다면, 10라인에 result를 저장하고 반환한다. 여기서 result에 할당할때 예외가 발생한다면, 스택c는 그 상태를 유지된 채로 괜찮다.

하지만, 사용자가 다음과 같이 이용하게 스택c를 유지할수 없는 상태가 될 수도 있다.

1라인에서 스택c에서 값을 뺀것이 s1에 들어가려 할때, 즉, 복사 생성자 호출 시 예외가 발생 될수 있고, 3라인에서도 복사 할당자에서 예외가 발생 할 수도 있다. 그러면 Pop을 했으므로 스택은 사용되지도 못하는 데이터를 꺼낸 꼴이 되고야 만다. 이것은 아무리 스택을 예외에서 안전하도록 만든다 하더라도, 그 데이터를 사용하지 못하게 된다면, 스택이 예외에서 안전치 못하다는 꼴이 되는 것이다.

하나의 대안으로는..

이런식으로 구성해 볼법 하다. 그리고 우리에게 두가지 인식을 가져다 준다. 스택은 최상위 요소를 뽑아내는 일과 뽑아낸 값을 반환하는 일에 있어, 예외를 어떻게 처리해야 할 것인지에 대한 인식들이다.

일반적인 실수로 예외 위험과 서툰 디자인이 맞물리게 되는 형태가 있다. 이 때 일반적인 실수를 고치면 그만이지만 서툰 디자인을 고치기에는 많은 인력을 들어오게 된다. 그러므로 코드를 짜게 될때, 각 기능을 조각 내어, 조각들 스스로가 자신의 책임을 다하는 구조로 가야 한다는 것이다.

총평
예외라는것이 좀 복잡하긴 하다. 몇가지 예외 안전성을 하기 위한 조건이 머리속에 들어 왔다.
1. 스택의 데이터에 변경이나 추가 작업이 있을 경우, 예외에 안전한지 생각해 봐야 한다.
2. 임시 객체를 이용하고, 임시객체에 다 값이 들어갔다면 마지막에 그 임시객체로 정리 한다.
3. 사용자 입장에서 이 객체를 어떻게 사용할 지도 생각해 봐야 한다.

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기