항목 10 : 예외에 안전한 코드를 작성하기 - 파트 3 (난이도 9½)

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

template <class T> class Stack { public: Stack(); ~Stack(); Stack( const Stack& ); // 복사 생성자 Stack& operator=( const Stack& ); // 복사 할당자 private: T* v_; // T의 vsize_를 위해 size_t vsize_; // 충분히 큰 메모리를 가리키는 size_t vused_; // 포인터 T의 실제 사용 개수 };

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

Count( )

template<class T> size_t Stack<T>::Count() const { return vused_; }

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

Push( )

template<class T> void Push( const T& t ) { if( vsize_ == vused_ ) { // 새로운 객체 만들고 T* v_new = NewCopy( v_, vsize_, vsize_ * 2 + 1 ); delete[] v_; // 예외를 일으키지 않고 v_ = v_new; // 소유권 이전하고 vsize_ = vsize_ * 2 + 1; // 사이즈 넣고 } v_[vused_] = t; ++vused_; }

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

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

Pop()

template <class T> T Stack<T>::Pop() { if( vused_ == 0 ) { throw "pop from empty stack"; } else { T result = v_[vused_ - 1]; --vused_; return result; } }

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

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

string s1( s.Pop() ); string s2; s2 = s.pop();

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

하나의 대안으로는..

template<class T> void Stack<T>::Pop( T& result ) { if( vused_ == 0 ) { throw "pop form empty stack"; } else { result = v_[vused_ - 1]; --vused_; } }

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

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

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