Zaawansowane CPP/Wykład 13: Wyjątki

Uwaga: przekonwertowane latex2mediawiki; prawdopodobnie trzeba wprowadzić poprawki

Wstęp

Jesteśmy istotami omylnymi, więc niezależnie od naszych starań nasze programy bedą zawierały usterki, dostarczane do nich dane nie zawsze będą poprawne, a i sprzęt nie zawsze będzie działał tak jak trzeba.

Nie oznacza to, że należy zaniechać dążenia do pisania bezbłednego kodu, wprost przeciwnie, jakość kodu powinna być jednym z naszych piorytetów, ale należy się też pogodzić z faktem, że błędy bedą występować i powinniśmy być na takie sytuacje przygotowani, jak to mówią "najwyższą formą zaufania jest kontrola".

Na potrzeby tego wykładu zdefiniujemy bardzo luźno błąd jako wystąpienie sytuacji, która wystąpić nie powinna. Nie będziemy też interesować się bardzo tym jak błedy wykrywać, ale raczej co zrobić kiedy takowy wykryjemy. W następnym podrozdziale omówię bardzo pobieżnie różne możliwości reakcji na wystąpienie błedu i wprowadzę pojęcie wyjątku. Reszta wykładu będzie poświęcona zagadnieniom związanym z pisaniem kodu używającego wyjątki.

Wykrywanie błedów

Jak już napisałem we wstępie chciąłbym od razu przejść do sytuacji, w której wiemy że wystapił błąd. Jednak muszę poświęcić najpierw kilka akapitów na zastanowienie się, czy w ogóle należy będy wykrywać i obsługiwać. Nawet jeśli większość z państwa krzyknie "oczywiście, że tak" (choć podejrzewam że większość tego sama nie robi: kto ostatnio sprawdzał wartość zwróconą przez funkcję printf?), to i tak pozostaje pytanie jakie błedy będziemy starali się wykrywać.

Na to pytanie nie ma jednoznacznej odpowiedzi, jak zresztą na większość pytań dotyczących decyzji projektowych. Różne projekty wymagają różnego poziomu niezawodności, a więc i różnych zabezpieczeń.

Na jednym końcu są programy, które po prostu nie mogą "paść", na drugim np. niektóre moje progamy symulacyjne, które wykonują się w godzinę lub mniej. Nawet jednak w tej ostatniej sytuacji, różne formy obsługi błędów mogą nam bardzo pomóc w debugowaniu. Linijki typu:

if( NULL==(fin=fopen(input_file_name,"r"))) { 
    fprintf(stderr,"cannot open file input_file_name);
    exit(1); }
}

lub

if( NULL==(p=malloc(n_bytes))) { 
    fprintf(stderr,"cannot allocate memory for ...");
    exit(1); 
  }
}

mogą nam oszczedzić, jeśli nie godzin, to wielu minut frustracji. Proszę zwrócić uwagę że oba przykłady dotyczą zasobów zewnętrznych, nie do końca pod naszą kontrolą i tym bardziej powinny być sprawdzane, zwłaszcza, że to będzie nas kosztować minutę pisania i prawie tyle co nic w trakcie wykonania.

Kontrola zakresu

A co z bardziej kosztownymi testami? Typowym przkładem jest sprawdzanie zakresu. Czy np. nasz stos Stack powinien sprawdzać, czy wykonujemy pop lub top na stosie pustym, albo push na stosie pełnym? Czy pwonniśmy sprawdzać poprawność podanego indeksu w wyrażeniach v[i]?

Mam nadzieję że państwo nie oczekują jednoznacznej odpowiedzi na te pytania, bo jej poprostu nie ma. Niestety tego rodzaju testy mogą być bardzo kosztowne. Operacje dostępu do elementów są bardzo proste, koszt testu będzie pewnie dominujący, a te operacje mogą być bardzo często wykonywane. Z drugiej strony błedy przekroczenia zakresu są bardzo "wredne". Rozważmy np. taki prosty kod:

Stack<int,5> s;
  
  for(int i=0;i<1000;i++)
    s.push(i);

  int i=0;
  while(1) 
    std::cerr<<++i<<" "<<s.pop()<<"";
/* {mod13/code/overflow.cpp}{overflow.cpp} */

Na moim komputerze powyższy program, wykonał 20981 operacji pop(), zanim padł z komunikatem Naruszenie ochrony pamięci. Proszę zauważyć że najpierw zapisał 995 liczb w pamięci należacej nie wiadomo do kogo! Skutki takiego błedu mogą więc wystapić w zupełnie innym miejscu programu.

Nie ma dobrego rozwiązania tego dylematu, ale zawsze może pomóc zdrowy rozsądek. Użycie sprawdzenia zakresu w operacji mnożenia macierzy, miałoby katastrofalne skutki dla wydajności kodu. Z drugiej strony jest to prosty kod w którym łatwo zapewnić aby indeksy nie wychodziły poza zakres. Tutaj więc kontrola zakresu jest niewskazana.

Częstym rozwiązaniem jest właczanie kontroli zakresu podczas debugowania i wyłączanie jej w "produkcyjnej" wersji programu. Moim zdaniem, może to być bardzo pożyteczne, zwłaszcza w językach które dopuszczają właczanie i wyłączanie sprawdzania zakresów za pomocą opcji kompilacji (oczywiście może to dotyczyć tylko typów wbudowanych). W przypadku stosu, mogą nam się przydać w tym celu klasy wytyczne, opracowane w rozdziale Uzupelnic lbl:wytyczne|. Może warto dodać, że kontenery STL, dostarczające operację indeksowania, dostarczają również metodę dostępu ze sprawdzaniem: at(int).

Obsługa błędów

Załóżmy więc, że w pogramie mamy przynajmniej kilka linijek wykrywających potencjalne błedy. No i stało się, wiemy już, że w programie wystąpił bład, co teraz? Mamy wiele możliwości, wymienię tylko kilka z nich:

1. Kończymy program z ewentualnym komunikatem o błędzie.
2. Kończymy program, ale najpierw sprzątamy po sobie: zwalniamy zasoby, których nie zwolni system operacyjny, zapisujemy dane, itp.
3. Staramy się kontynuować program pomimo błądu, próbując go poprawić, obejść lub zrezygnować z części funkcjonaności.

W tym wykładzie nie będzi interesować nas sama konkretna strategia, ale sposób rozdzielenia procesu wykrycia błędu od wyboru strategii. Jest to problem który dotyczy każdego kodu, ale głównie funkcji bibliotecznych. Ich projektant/programista może wykryć, że w trakcie ich wykonywania wystąpiła nieprawidłowość, ale nie może jednak wiedzieć jak z takim błędem postąpić. To jest decyzja osoby korzystającej z tej funkcji. Musi więc istnieć jakiś mechanizm przekazywania tej informacji z wywoływanej funkcji na zewnątrz do funkcji wywołującej.

Najprostyszym sposobem jest zwrócenie jakiejś wartości sygnalizującej błąd. Jeśli funkcja nie zwraca żadnego wyniku, to jest to proste, jeśli jednak funkcja ma zwracać jakiś wynik, to nie zawsze da się znaleźć taką wartość, która by jednoznacznie mogła definiować błąd. Rozszerzenia tej metody, to zwrócenie informacji o przebiegu funkcji porzez dodatkowy argument przekazywany przez referencje. Można też ustawiać i odczytywać jakieś zmienne stanu. Największą wadą tego podejścia jest konieczność każdorazowego sprawdzania tych wartości, co wymaga pisania dużej ilości trywialnego kodu. Z tego powodu sprawdzania poprawności wywołania takich funkcji jest często opuszczane. W C++ dochodzi jeszcze niemożność zwrócenia wartości z konstruktora (choć oczywiście możemy ustawić w nim zmienną stanu informująco o powodzeniu konstrukcji).

Wyjatki

C++ dostarcza nowego mechanizmu, są to wyjątki. Polega on na tym, że funkcja która bład wykryje i nie chce lub nie może go obsłużyć sama, rzuca wyjątek, który może być dowolnym obiektem. Rzucenie wyjątku powoduje natychmiastowe przerwanie wykonywania funkcji. Procedura wywołująca może ten wyjątek złapać. Wyjątek niezłapany prowadzi do zatrzymana programu, a więc wyjątki nie mogą zostać zignorowane. Zilustruję to na przykładzie naszego stosu, do którego dodam instrukcje rzucające wyjątki, w przypadku przekroczenia zakresu (dla prostoty nie będę korzystał z klas wytycznych):

template<typename T = int , size_t N = 100> class Stack {
private:	
  T _rep[N];
  size_t _top;
public:
  Stack():_top(0) {};
  void push(T val) {
    if(_top == N) {
      throw "pushing on top of the full stack";
    }
    _rep[_top++]=val;
  }
  T pop() {
    if(is_empty()) {
      throw "poping form an empty stack";
    }
    return _rep[--_top];
  }
  bool is_empty() const     {return (_top==0);} 
};
/* {mode13/code/stack_except.h}{stackexcept.h}*/

Polecenie throw służy właśnie do rzucania wyjątków. W tym wypadku rzucane są stałe napisowe, które będą automatycznie konwertowane na typ const char *. Wykonanie programu

main() {
  Stack<int,5> s;
  s.push(1);
  s.pop(); 
  s.pop(); /* tu będzie rzucony wyjątek */
  
  for(int i=0;i<10;i++) 
  s.push(i); /* tu też gdyby udało się tu dojść */
}
/* {mod13/code/overflow.cpp}{overflow.cpp} */  

spowoduje przerwanie programu w trakcie wykonywania drugiego polecenia pop. Komunikat, który się przy tym pojawia jest zależny od implementacji.

Wyjątki można łapać korzystając z bloku try.

Stack<int,5> s;
  s.push(1);
  try {
    s.pop();
    s.pop();
  }
  catch(const char *msg) {
    std::cerr<<msg<<std::endl;
  }
  try {
      for(int i=0;i<10;i++) 
    s.push(i);
  }
  catch(const char *msg) {
    std::cerr<<msg<<std::endl;
  }
/* {mod13/code/stack_except.cpp}{stackexcept.cpp} */

W bloku try umieszczamy instrukcje które mogą potencjalnie rzucić wyjątek. Za blokiem try umieszczamy jedną lub więcej klauzul catch które te wyjątki łapią. Wyjątek rzucony w bloku try powoduje przekazanie sterowania do pierwszej pasującej klauzuli catch.

Wyjatki złapane

Przyjrzyjmy się teraz dokladniej mechanizmowi rzucania i łapania wyjątków. Rozważmy prosty przykład:

struct X {
  int val;
  X(int i=0):val(i) {cerr<<"constructing "<<val<<"";}
   X() {cerr<<"destructing "<<val<<endl;}  
};

void f()  {
  X x(1);
  throw 0;
  cout<<"f";
};

main(){
  X  y(2);
  try {
    X z(3);
    f();
    cout<<"try";
  } 
  catch(double){cout<<"zlapalem double-a";}
  catch(int){cout<<"zlapalem int-a";}
  catch(...){cout<<"zlapalem cos ";}

 cout<<"main";
}
/* {mod13/code/caught.cpp}{caught.cpp} */

Oto wynik wykonania tego programu:

constructing 2
constructing 3
constructing 1
destructing 1
destructing 3
zlapalem int-a
main
destructing 2

Co możemy zauważyć?

1. Wyjątek przerwał wykonywanie funkcji f() i bloku try, sterowanie zostało przekazana do klauzuli catch(int).
2. Przedtem wywołane zostały destruktory obiektów x i z, czyli lokalnych obiektów w zasięgu bloku try. Ten proces nazywamy "zwijaniem stosu".
3. Po wykonaniu klauzuli catch sterowanie zostało przekazane do następnego wyrażenia.

Klauzula catch(...) wyłapuje każdy wyjatek, jeśli np. pominiemy klauzule catch(int):

catch(double){cout<<"zlapalem double-a";}
//catch(int){cout<<"zlapalem int-a";}
catch(...){cout<<"zlapalem cos ";}

to wynikiem wywołania programu będzie:

constructing 2
constructing 3
constructing 1
destructing 1
destructing 3
zlapalem cos
main
destructing 2

Z tego przykładu widać też, że w przypadku dopasowywania klauzul catch nie następuje niejawna konwersja argumentów.

Nie złapane wyjątki

A co się stanie, jeśli wyjątku nie złapiemy ? Zeby się o tym przekonać usuniemy kolejną klauzulę catch:

catch(double){cout<<"zlapalem double-a";}
//catch(int){cout<<"zlapalem int-a";}
//catch(...){cout<<"zlapalem cos ";}

Wynik programu jest teraz zupełnie inny:

constructing 2
constructing 3
constructing 1
terminate called after throwing an instance of 'int'
Abort

Niezłapany wyjątek spowodował wywołanie funkcji abort(), która zakończyła program bez wywołania destruktorów. Sciśle rzecz biorąc, niezłapany wyjątek wywołuje funkcję terminate(), która z kolei domyślnie wywołuje funkcję abort(). Co do tego, czy wywoływane są destruktory lokalnych obiektów (zwijanie stosu), to jest to zachowanie zależne od implementacji. Jak widać, w implementacji g++, w przypadku niezłapania wyjątku destruktory obiektów nie są wywoływane.

Domyślne zachowanie funkcji terminate() można zmienić, ustawiając własną funkcje, za pomocą:

namespace std {
typedef void (*terminate_handler)(void);
terminate_handler set_terminate(terminate_handler new_terminate);
}

Funkcja ustawiana w tym poleceniu nie może zwrócić sterowania, taka próba kończy sie wywołaniem funkcji abort(). Oznacza to, że funkcja new_terminate() musi kończyć się wywołaniem abort() lub exit().

void my_terminate() {std::cerr<<"terminating "<<std::endl;exit(1);}

main() {
  std::set_terminate(my_terminate);
  throw 0;
}
/* {mod1/code/terminate.cpp}{terminate.cpp}*/

Wyjątki w destruktorach

Jeśli podczas opisanego powyżej procesu obsługi wyjątku, wywołana zostanie funkcja która sama wywoła wyjątek, to program zostanie natychmiast przerwany wykonaniem funkcji terminate() (nie dotyczy to już funkcji wywoływanych wewnątrz klauzuli catch). W szczególności stanie się to jeśli któryś z destruktorów wywoływanych w trakcie zwijania stosu rzuci wyjątek:

struct X {
   X() {
    std::cerr<<std::uncaught_exception()<<"";
    throw 0;};
} ;

main() {
  try 
    {
      X x;
    }
  catch(int) {};
  
  try {
    X x;
    throw 0;
  }
  catch(int) {};
}
/* {mode13/code/destruktor.cpp}{destruktor.cpp} */

W powyższym kodzie destruktor klasy X jest wołany dwa razy. Po raz pierwszy, podczas wychodzenia z pierwszego bloku try. Jest to normalne wywołanie spowodowane wyjściem poza zakres. Destruktor rzuca wyjątek, który zostaje wyłapany poprzez klauzulę catch(int) na końcu bloku. Drugi raz, destruktor jest wołany jako część zwijania stosu po wyjątku rzuconym jawnie w drugim bloku try. Mimo, że łapiemy wyjątki int, i tak w tej sytuacji wywoływana jest funkcja terminate(), a w konsekwencji i abort(). Jest to jeden z powodów, dla których destruktory nie powinny rzucać wyjątków. Funkcja uncaught_exception() umożliwia rozróżnienie tych dwu kontekstów wywołania destruktora. Zwraca ona prawdę jeśli jakiś wyjątek jest właśnie obsługiwany.

Inne powody nie rzucania wyjątków z destruktorow, wiążą się z dynamicznym alokacja pamięci i zostaną omówione w kolejnym wykładzie.

Hierachie wyjątków

Jako wyjątek może zostać wyrzucony dowolny obiekt. Umożliwia nam to grupowanie wyjątków w hierarchie, za pomocą dziedziczenia. Zilustrujemy to za pomocą hierachii wyjątków z biblioteki standardowej, przedstawionej na rysunku Uzupelnic fig:exceptions|.

[p]
 

{Hierarchia wyjątków biblioteki standardowej.}

Można z niej korzystać np. następująco:

main() {
  try {
        throw domain_error() ;
  }
  catch(invalid_argument &e) {
    cerr<<e.what()<<"";
  }
  catch(logic_error &e) {
    cerr<<"logic "<<e.what()<<"";
  }
  catch(exception &e) {
    cerr<<"some exception "<<e.what()<<"";
  } 
}
/* {mod13/code/hierarchy.cpp}{hierarchy.cpp}

Kolejność klauzul catch jest ważna, ponieważ klauzule są sprawdzane po kolei, i pierwsza która pasuje zostanie wykonana. Gdybyśmy więc podali kaluzulę catch(Exception &e) jako pierwszą, przechwyciła by ona wszyskie standardowe wyjątki. Ważne jest też, aby korzystając z hierarchii dziedziczenia przechwytywać wyjątki przez referencję. Inaczej nie zostaną wywołane poprawne funkcje wirtualne. Zachęcam do eksperymentów z powyższym kodem.

Deklaracje wyjatków

C++ pozwala na deklarowanie listy możliwych wyjątków rzucanych z funkcji. Służy do tego deklaracja throw(...) umieszana za deklaracją listy argumentów funkcji np.:

void no_throw(int) throw();

deklaruje, że funkcja no_throw nie rzuci żadnego wyjątku, natomiast

void throw_std(int) throw(exception);

deklaruje, że funkcja throw_std będzie rzucać tylko wyjątki ze standardowej hierarchi. Brak deklaracji oznacza, że funkcja może rzucać co chce.

Niestety, C++ nie dostarcza nam praktycznie żadnych mechanizmów, które by mogły wymusić konsystencję tych deklaracji. Rozważmy implementację funkcji:

void f(int i) {throw i;}
void g() throw(int) {throw 0;}; 
void no_throw(int i) {f(i;};

Funkcja f proklamuje całemu światu, że może rzucać wyjątek (poprzez brak deklaracji, że nie może), podobnie funkcja g(), a pomimo to kompilator nie pozwala na to, aby wywołać ją wewnątrz funkcji która jawnie deklaruje, że wyjątku nie rzuci. Proszę to porównać np. ze zastosowaniem kwalifikatora const: funkcja zadeklarowana jako const nie może wołać funkcji, które const nie są. W przypadku wyjątków narzucenie takiej konsystencji spowodowałoby to, że potrzeba by przerabiać ogromne ilości kodu, napisanego zanim mechanizm wyjątków stał się używany. Sprawia to niestety, że deklaracje wyjątków nie są zbyt użyteczne, łatwo bowiem niechcący napisać kod który je złamie. A konsekwencje tego są poważne. Sprawdzania konsystencji w czasie kompilacji wprawdzie nie ma, ale jest sprawdzanie w czasie wykonania. Jeżeli funkcja rzuci wyjątek, który nie znajduje się na jej liście zadeklarowanych wyjątków, to następuje wywołanie funkcji unexpected(), która domyślnie wywołuje abort(). Nawet złapanie tego wyjątku nic nie pomoże.

Kolejnym problem są szablony funkcji i metody szablonów klas. Ich projektant nie może przewidzieć z jakimi argumentami zostaną one konkretyzowane, a więc jakie wyjątki mogą zostać rzucone. Dlatego w szablonach lepiej deklaracje wyjątków pomijać. W ogóle, deklaracje wyjątków należy umieszczać tam, gdzie uważamy, że rzucenie każdego innego wyjątku jest przejawem poważnego błedu. Najczęściej jest to sytuacja, kiedy chcemy zadeklarować, że dana funkcja w ogóle nie rzuca wyjątków. Jak już pisałem taką własność powinny posiadać destruktory.

Niespodziewane wyjątki

Podobnie jak w przypadku funkcji terminate() możemy podstawić własną funkcję unexpected(). Podobnie jak terminate() funkcja unexpected() nie zwraca sterowania, może za to sama rzucić wyjątek. W ten sposób możemy jej użyć do "podmiany" niespodziewanego wyjątku na inny. Zobaczmy jak to działa:

void f() throw(int) {
  throw "niespodzianka!";
};

main() {
  try {
  f();
  }
  catch(...) {};
}
/* {mod13/code/unexpected.cpp}{unexpected.cpp} */

Ponieważ f() rzuca const char *, a deklaruje tylko int-a, powyższy program wywoła funkcję unexpected(), która przerwie program. Jeżeli podmienimy wyjątek poprzez ustawienie odpowiedniej funkcji:

void unexpected_handler() {throw 0;};
std::set_unexpected(unexpected_handler);

to zamiast const char * zostanie rzucony int i złapany przez klauzulę catch(...). Tak się stanie ponieważ int jest na liście wyjątków funkcji f(). Gdyby nie był, to zostałaby wywołana funkcja terminate(). Jeżeli jednak deklaracja wyjątków funkcji f() zawierać będzie wyjatek std::bad_exception, to każdy wyjątek rzucony przez unexpected() i nie znajdujący się na liście zadeklarowanych wyjątków funkcji f() jest podmienieny na std::bad_exception():

void f() throw(int,std::bad_exception) {
  throw "niespodzianka!";
};

void unexpected_handler() {throw 3.1415926;};

main() {
  std::set_unexpected(unexpected_handler);
  try {
  f();
  }
  catch(std::bad_exception ) {};
}
/* {mod13/code/unexpected.cpp}{unexpected.cpp} */

Wydajność wyjątków

Autor pozycji {MeyersMECPP} sugerował, że użycie mechanizmu wyjątków może spowolnić program, nawet jeśli wyjątki nie będą rzucane. Ponieważ od tego czasu minęło dobrych kilka lat, postanowiłem sam sprawdzić jak się sprawy mają. W tym celu skorzystałem z następujących programików:

double scin(double x,bool flag) {
  if(flag) throw 0;
  return sin(x);
}
main(){
  volatile int f=0;
  double s=0.0;
  for(int i=0;i<100000000;++i) {
    try {
    s+=scin(rand()/(double)RAND_MAX,f);
    } catch(int) {};
  }
}
/* {mod13/code/exceptions.cpp}{exceptions.cpp} */

oraz

double scin(double x,bool flag) {
  if(flag) return 0;
  return sin(x);
}

main(){
  volatile int f=0;
  double s=0.0;
  for(int i=0;i<100000000;++i)
    s+=scin(rand()/(double)RAND_MAX,f);
}
/* {mod13/code/no_exceptions.cpp}{noexceptions.cpp} */

Jak widać drugi z nich nie ma nawet śladu wyjątków. W pierwszym podejściu ustawilem flagę f na zero, co powodowało że żaden wyjątek nie był rzucany. Czas wykonania obu programów (w sekundach) podany jest w poniższej tabelce.

Uzupelnij tytul

	1 nie rzucane wyjątki	2 bez wyjątków	3 rzucane wyjątki	4 return
-O0	15	15
-O1	13	4
-O2	13	4
-O3	4	4	600	4

Porównując kolumny 1 i 2 widać że dla pełnej optymalizacji, nie ma żadnej różnicy. Szczegółowe badanie wykazało, że to włączenie opcji -finline-functions powoduje skok predkości pomiędzy dwoma ostatnimi wierszami w pierwszej kolumnie. Ten sam effekt można uzyskać dodając do funkcji scin kwalifikator inline.

Następnie porównałem koszt zwykłego powrotu z funkcji, z kosztem rzucenia wyjątku. Wyniki są przedstawione w dwóch ostatnich kolumnach tabelki. Tu widać dramatyczną różnicę: obsługa wyjątku jest ponad 100 razy wolniejsza.