Zaawansowane CPP/Wykład 15: Wyjątkowo odporny kod

Uwaga: przekonwertowane latex2mediawiki; prawdopodobnie trzeba wprowadzi� poprawki

{Wyjątkowo odporny kod}

Wstęp

W poprzednim wykładzie opisałem mechanizm obsługi błędów za pomocą wyjątków. Jest to bardzo silny mechanizm: rzucony wyjątek powoduje natychmiastowe przekazanie sterowania do najbliższej klauzuli catch, niejako "tnąc" w poprzek dowolnie głeboko zagnieżdżonych funkcji. To oczywiście jest jedną z jego podstawowych zalet, ale musimy podchodzić do tej własności bardzo ostrożnie.

W tym wykładzie zwrócę uwagę na kilka niebezpieczeństw wynikających z obsługi wyjątków i na sposoby zapobiegania im.

Wyjątkowe niebezpieczeństwa

W zasadzie korzystanie z wyjątków jest proste: funkcja, która stwierdza wystąpienie błądu, a nie umie go sama obsłużyć, przekazuje odpowiedzialność swoim przełożonym, rzucając wyjątek. Jej przełożeni mogą zrobić to samo(wystarczy, że nie przechwycą wyjątku). Zakładamy jednak, że gdzieś w tej hierarchi wyjątek zostanie złapany przez kogoś, kto wie jak go obsłużyć. W praktyce sprawa może być bardziej skomplikowana. Rzucony wyjątek powoduje natychmiastowe przerwanie, nie tylko funkcji, która go rzuciła, ale również wszystkich funkcji przez, które "przelatuje". Jeśli te funkcje nie są na to przygotowane, to wyjątek może narobić dodatkowych szkód. Typowy przykład to niezwolnione zasoby:

void f() {
przydziel_zasob();
g(); /*może rzucić wyjątek*/
zwolnij_zasob(); 
}
 

Rzucenie wyjątku z g() spowoduje wyciek zasobu (zwykle pamięci). Taki przykład był już rozważany w wykładzie Uzupelnic lbl:smart_ptr|. Podane tam rozwiązanie, to technika "przydział zasobu jest inicjalizacją", czyli oddelegowanie zarządzania zasobem do osobnej klasy, której konstruktor, przydziela zasób, a destruktor zwalnia:

void f() {
Zasob x;
g(); /*może rzucić wyjątek*/
} /* niejawnie wyływany  destruktor x. Zasob() */
 

Wtedy podczas zwijanie stosu zasób zostanie zwolniony automatycznie. Proszę zauważyć jednak, że jeśli nie przechwycimy wyjątku, to zasób może dalej pozostać nie zwolniony. Rozwiązaniem może być kod:

void f() {
przydziel_zasob();
try {
g(); /*może rzucić wyjątek*/
}
cath(...) {zwolnij_zasob();throw;}
 
zwolnij_zasob(); 
}
 

po zwolnienie zasobu rzucamy (podrzucamy?) ponownie ten sam wyjątek. W ten sposób funkcja f() staję się "przeźroczysta dla wyjątków" (exception--neutral).

Konstruktory

Szczególnym przypadkiem mogącym prowadzić do wycieku pamięci są wyjątki rzucane z konstruktora. Rozważmy następujący kod:

struct BigRsource {
char c[10000000];
};
struct BadBoy {
  BadBoy() {throw 0;};
};

struct X {
  BigResource *p1;
  BadBoy      p2;
  X: p1(new BigResource) {}

 X() {
  delete p1;
  }
}
 

Na pierwszy rzut oka jest to pierwszorzędowy przykład programowania obiektowego: pamięć jest przydzielana w konstruktorze i zwalniana w destruktorze, nie ma więc możliwości wycieku. Prześledźmy jednak, co się stanie gdy napiszemy:

try {
X x;
} catch(...) {};
 

Konstruktor najpierw przydzieli pamięć dla wskaźnika p1. Załóżmy, że ta alokacja się powiedzie. Następnie zostanie wywołany konstruktor BadBoy, który rzuci wyjątek. Wyjątek nie zostanie złapany w konstruktorze X, więc sterowanie zostane przekazane do klauzuli catch. Nastąpi zwinięcie stosu, ale destruktor obiektu x nie zostanie wywołany! Dzieje się tak dlatego, że w C++ destruktory nie są wołane dla obiektów, których konstrukcja się nie powiodła. W taki sposób tracimy 10MB. Możliwe rozwiązania są podobne jak w poprzednim wypadku: korzystamy z auto_ptr:

struct X {
  std::auto_ptr<BigResource> p1;
  BadBoy      p2;
  X: p1(new  BigResource) {}

 X() {
  delete p1;
  }
};
 

lub sami łapiemy wyjątek:

struct X {
  BigResource *p1;
  BadBoy      p2;
  X: try {p1(new BigResource) {}}
  catch(...){delete p1;};

 X() {
  delete p1;
  }
}
 

Proszę zwrócić uwagę na blok try, który otacza cały konstruktor łącznie z listą inicjalizatorów.

The bad, the good and the ugly

Jeżeli wyjątek został rzucony przez metodę jakiegoś obiektu, to dla dalszego działania programu ważne jest, w jakim stanie go pozostawił. Wyróżnimy trzy możliwości:

Obiekt jest w stanie niekonsystentnym, nie

są zachowane niezmienniki jego typu, być może nastąpił wyciek zasobów. Nieokreślone jest zachowanie wywoływanych metod, w szczególności może

nie powieść się destrukcja obiektu.

Obiekt jest w stanie konsystentnym, ale

niezdefiniowanym.

Obiekt pozostaje w stanie, w jakim był przed

rzuceniem wyjątku. Jest to semantyka transakcji: commit--rollback.

Ewidentnie najbardziej pożądanym zachowaniem jest stan ostatni. Nie zawsze da się jednak zapewnić takie zachowanie bez ponoszenia dużych kosztów. Wtedy możemy zadowolić się stanem drugim. Stan pierwszy to oczywista katastrofa.

Przykład: stos

Rozważmy stos z dynamiczną obsługą pamięci. Przykład takiego stosu był podany w wykładzie Uzupelnic lbl:wytyczne|. Żeby nie wprowadzać komplikacji, nie będziemy tu korzystać z klas wytycznych:

template <class T,size_t N <nowiki>= 10> class Stack {
 size_t nelems;
 size_t top;
 T* v;

public:

 bool is_empty() const;
 void push(const T&);
 T pop();

 Stack(size_t n = N);
  Stack();
 Stack(const Stack&);
 Stack& operator=(const Stack&);

}; </nowiki>

Przyjrzyjmy się teraz po kolei jego metodom, zaczynając od konstruktorów:

template <class T,size_t  N> Stack<T,N>::Stack(size_t n):
  nelems(n),top(0),v(new T[nelems]) {};
 

W powyższym konstruktorze może nie powieść się tylko operacja tworzenia tablicy v. Ale wtedy zgodnie z tym co już omawialiśmy w poprzednim wykładzie, wyrażenie new samo po sobie posprząta. Nie mamy się co martwić stanem pozostawionego obiektu, bo jeśli konstrukcja się nie powiedzie, to obiektu po prostu nie ma.

Z konstruktorem kopiującym jest już trochę gorzej:

template <class T,size_t N>  Stack<T,N>::Stack(const Stack<T,N>& s):
v(new T[nelems <nowiki>= s.nelems]) {
 if( s.top > 0 )
 for(top = 0; top < s.top; top++)
 v[top] = s.v[top]; /* tu może zostać rzucony wyjatek */  

} </nowiki> Podobnie jak poprzednio, w wypadku niepowodzenia wyrażenie new posprząta po sobie. Ale wyjątek może zostać rzucony również poprzez operator przypisania klasy T. Wtedy będziemy mieli do czynienia z wyciekiem pamięci, ponieważ nie zostanie wywołany destruktor stosu, który zwalnia pamięć v. Taki przykład już omawialiśmy na początku wykładu. Rozwiązaniem jest użycie auto_ptr lub przechwycenie wyjątku:

template <class T,size_t N>  Stack<T,N>::Stack(const Stack<T,N>& s):
v(new T[nelems <nowiki>= s.nelems]) {
 try {
   if( s.top > 0 )
   for(top = 0; top < s.top; top++)
   v[top] = s.v[top]; /* tu może zostać rzucony wyjatek */  
 }
 catch(...) {
   delete [] v; throw ;
 }

} </nowiki> To rozwiązanie zakłada, że destrukcja v powiedzie się, tzn., że operator przypisania:

v[top] <nowiki>= s.v[top];

</nowiki> pozostawił lewą stronę w stanie umożliwiającym jej destrukcję.

Sytuacja jest groźniejsza w przypadku operatora przypisania:

template <class T,size_t N> Stack<T,N>&
Stack<T,N>::operator<nowiki>=(const Stack<T,N>& s) {
 delete [ ] v;
 v = new T[nelems=s.nelems];
 if( s.top > 0 )
 for(top = 0; top < s.top; top++)
    v[top] = s.v[top];
 
 return *this;

} </nowiki> Wyjątek rzucony przez wyrażenie new zostawia stos w stanie złym z wiszącym luźno wskaźnikiem v. Wyjątek rzucony przez operator przypisania elementów tablicy v w najlepszym przypadku zostawia stos w stanie niezdefiniowanym. Implementacja, która w wypadku wystąpienia wyjątku zostawia stos, w takim stanie w jakim go zastała jest podana poniżej:

template <class T,size_t N> Stack<T,N>&
Stack<T,N>::operator<nowiki>=(const Stack<T,N>& s) {
 T *tmp;
 try {
   tmp = new T[nelems=s.nelems];
   if( s.top > 0 )
     for(size_t i = 0; i < s.top; i++)
         tmp[i] = s.v[i];
  }
  catch(...) {delete [] tmp,throw;}
  swap(v,tmp);
  delete [] tmp;
  top=s.top;
  
  return *this;

} </nowiki>

Przejdźmy teraz do podstawowych funkcji stosu, zaczynając od funkcji push:

template <class T,size_t N>
void Stack<T,N>::push(const T &element) {
  if( top <nowiki>== nelems ) {
   T* new_buffer = new T[nelems += N];
   for(int i = 0; i < top; i++)
     new_buffer[i] = v[i];
   delete [] v;
   v = new_buffer;
 }
   
 v[top++] = element;

} </nowiki> Załóżmy na początek, że nie ma potrzeby zwiększania pamięci, wykonywane jest więc tylko polecenie:

v[top++] <nowiki>= element;

</nowiki> Jak już zauważyliśmy, przypisanie może się nie powieść, wtedy stos zostanie w stanie złym lub niezdefiniowanym, ponieważ top zostanie zwiększone. Lepiej jest więc napisać:

v[top] <nowiki>= element;
 ++top;

</nowiki> Zobaczmy, co się dzieje, jeśli zażądamy zwiększenia pamięci. Niepowodzenie wyrażenia new zostawi nas ze zwiększonym polem nelems pomimo, że pamięć się nie zwiększyła. Wyjątek z operatora przypisania zostawi nas z wyciekiem pamięci, ponieważ pamięć przydzialona do new_buffer nigdy nie zostanie zwolniona. Uwzględaniając te uwagi, poprawimy funkcję push następująco:

template <class T,size_t N>
void Stack<T,N>::push(T element) {
  if( top <nowiki>== nelems ) {
   T* new_buffer;
   size_t new_nelems;
   try {
     new_nelems=nelems+N;
     new_buffer = new T[new_nelems];
     for(int i = 0; i < top; i++)
       new_buffer[i] = v[i];
   }
   catch(...) { delete [] new_buffer;}
     swap(v,new_buffer);
     delete [] new_buffer;
     nelems = new_nelems;
   }

 v[top] = element;
 ++top;
 }

</nowiki>

Na koniec została nam jeszcze funkcja pop:

template <class T,size_t N> T Stack<T,N>::pop() {
  if( top <nowiki>== 0 )
   throw std::domain_error("pop on empty stack");
 return v[--top]; /* tu może nastąpić kopiowanie */

} </nowiki> Jak widać funkcja pop może rzucić jawnie wyjątek std::domain_error. Z tym wyjątkiem nie ma problemów. Potencjalny problem stwarza za to wyrażenie:

return v[--top]; /* tu może nastąpić kopiowanie */
 

Ponieważ zwracamy v[--top] przez wartość, to może nastąpić kopiowanie elementy typu T. Nie musi, ponieważ kompilator ma prawo wyoptymalizować powstały obiekt tymczasowy. Jeżeli jednak zostanie wywołany konstruktor kopiujący, to może rzucić wyjątek. Wtedy stos pozostanie w zmienionym stanie, bo wartość top zostanie zmniejszona. Rozważmy też wyrażenie:

x <nowiki>= s.pop(); 

</nowiki> Jeżeli operacja przypisania się nie powiedzie, to stracimy bezpowrotnie jeden element stosu. Można by powiedzieć, że to już nie jest sprawa stosu, ale lepiej po prosty rozdzielić operację modyfikujące stan stosu od operacji tylko ten stan odczytujących:

template <class T,size_t N> void Stack<T,N>::pop() {
  if( top <nowiki>== 0 )
   throw std::domain_error("pop on empty stack");
   --top;
 }

template<class T,size_t N> T &Stack<T,N>::top() {

 if( top == 0 )
   throw std::domain_error("pop on empty stack");

 return v[top-1];

} template<class T,size_t N> const T &Stack<T,N>::top() const {

 if( top == 0 )
   throw std::domain_error("pop on empty stack");

 return v[top-1];

} </nowiki> W przeciwieństwie do pop() operacja top() może zwracać wartość przez referencje. Funkcja pop() robić tego w ogólności nie mogła, bo potencjalnie niszczyła obiekt zdejmowany ze stosu.

Kolejny stos

Zaprezentowana w poprzedniej części implementacja stosu wymagała, aby parametr szablonu T posiadał:

• Konstruktor domyślny
• Bezpieczny (względem wyjątków) operator przypisania
• Desktruktor nierzucający wyjątków

Proszę zauważyć, że konstruktor domyślny właściwie niczemu nie służy. Jest potrzebny tylko po to, aby stworzyć tablicę obiektów, które potem będą tak naprawdę nadpisywane za pomocą operatora przypisania. Taka inicjalizacja i przypisanie jest w C++ dokonywana za pomocą konstruktora kopiującego. Na zakończenie przedstawię implementację klasy Stack, która od typu T potrzebuje tylko destruktora i konstruktora kopiującego. W tym celu będziemy przydzielać "gołą" pamięć oraz tworzyć i niszczyć w niej obiekty bezpośrednio. Do tego celu wykorzystamy alokator opisany w poprzednim wykładzie. Zaczniemy od zdefiniowania pomocniczej klasy do zarządzania pamięcią:

template<typename T,typename Allocator <nowiki>= std::allocator<T> > 

struct Stack_impl : public Allocator{

 size_t _top;
 size_t _size;
 T* _buffer;

 Stack_impl(size_t n):
   _top(0), 
   _size(n),
   _buffer(Allocator::allocate(_size)) {};
 
  Stack_impl() {
   for(size_t i=0;i<_top;++i)
     destroy(_buffer++);

   deallocate(_buffer,_size);
 }

 void swap(Stack_impl& rhs) throw() {
   std::swap(_buffer,rhs._buffer);
   std::swap(_size,rhs._size);
   std::swap(_top,rhs._top);
 }

}; </nowiki> Jedyne miejsce, gdzie może zostać rzucony wyjątek to funkcja allocate(), ale wtedy żadna pamięć nie zostanie przydzielona ani żaden obiekt nie zostanie stworzony. Korzystamy tu też z żądania, aby alokator był bezstanowy, inaczej funkcja swap musiałaby też zamieniać składowe alokatorów.

Klasa Stack korzysta z klasy Stack_impl:

template<typename T,size_t N <nowiki>= 10,
        typename Allocator = std::allocator<T> > 

class Stack { private:

 Stack_impl<T,Allocator> _impl;

/* {mod15/code/stack_sutter.h}{stacksutter.h} */ </nowiki>

Konstruktory:

public:
  Stack(size_t n <nowiki>= N):_impl(n) {};

 Stack(const Stack& rhs):_impl(rhs._impl) {
   while(_impl._top < rhs._impl._top) {
     _impl.construct(_impl._buffer+_impl._top, rhs._impl._buffer[_impl._top]);
     ++_impl._top;
   }
 } 

/* {mod15/code/stack_sutter.h}{stacksutter.h} */ </nowiki> robią się teraz prostsze. Nie ma potrzeby definiowania destruktora. Destruktor domyślny sam wywoła destruktor pola _impl. Jeżeli w konstruktorze kopiującym, zostanie rzucony wyjątek w funkcji construct, to wywołany podczas zwijania stosu destruktor Stack_impl wywoła destruktory stworzonych obiektów i zwolni pamięć.

Operator przypisania korzysta z "triku":

Stack &operator<nowiki>=(const Stack& rhs) {
   Stack tmp(rhs);
   _impl.swap(tmp._impl);
   return *this;
 }

/* {mod15/code/stack_sutter.h}{stacksutter.h} */ </nowiki> Tworzymy kopie prawej strony i zamieniamy z lewą stroną. Obiekt tmp jest obiektem lokalnym, więc zostanie zniszczony. Jeśli nie powiedzie się kopiowanie, to stos pozostaje w stanie niezmienionym. Proszę zauważyć, że jest to bezpieczne nawet w przypadku samopodstawienia s<nowiki>=s</nowiki>.

Funkcja push stosuje podobną technikę:

void push(const T &elem) {
    if(_impl._top<nowiki>==_impl._size) {

     Stack tmp(_impl._size+N);
     while(tmp._impl._top < _impl._top) {

_impl.construct(tmp._impl._buffer+tmp._impl._top, _impl._buffer[tmp._impl._top]); ++tmp._impl._top;

     }
     _impl.swap(tmp._impl);
   }
   
   _impl.construct(_impl._buffer+_impl._top,elem);
   ++_impl._top;
 }

/* {mod15/code/stack_sutter.h}{stacksutter.h} */ </nowiki>

Funkcje top() i pop() pozostają praktycznie niezmienione, z tym, że funkcja pop() niszczy obiekt na wierzchołku stosu:

T &top() {
    if(_impl._top<nowiki>==0)
     throw std::domain_error("empty stack");
   return _impl._buffer[_impl._top-1];
 }

 void pop() {
   if(_impl._top==0)
     throw std::domain_error("empty stack");
   
   --_impl._top;
   _impl.destroy(_impl._buffer+_impl._top);
 }

 bool is_empty() {
   return _impl._top==0;
 }

}; /* {mod15/code/stack_sutter.h}{stacksutter.h} */ </nowiki>