Tekst źródłowy strony 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ę <code>printf</code>?), 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<nowiki>=</nowiki><nowiki>=</nowiki>(fin<nowiki>=</nowiki>fopen(input_file_name,"r"))) { 
     fprintf(stderr,"cannot open file input_file_name);
     exit(1); }
 }
 
lub

 if( NULL<nowiki>=</nowiki><nowiki>=</nowiki>(p<nowiki>=</nowiki>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 <code>Stack</code> powinien 
sprawdzać, czy wykonujemy <code>pop</code> lub <code>top</code> na stosie pustym, 
albo <code>push</code> na stosie pełnym? Czy pwonniśmy sprawdzać 
poprawność podanego indeksu w wyrażeniach <code>v[i]</code>?

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<nowiki>=</nowiki>0;i<1000;i++)
     s.push(i);
 
   int i<nowiki>=</nowiki>0;
   while(1) 
     std::cerr<<++i<<" "<<s.pop()<<"";
 /* {mod13/code/overflow.cpp}{overflow.cpp} */
 
Na moim komputerze powyższy program, wykonał 20981 operacji <code>pop()</code>,
zanim padł z komunikatem <tt>Naruszenie ochrony pamięci</tt>.  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 [[##lbl:wytyczne|Uzupelnic lbl:wytyczne|]]. Może warto
dodać, że kontenery STL, dostarczające operację indeksowania,
dostarczają również metodę dostępu ze sprawdzaniem: <code>at(int)</code>.

==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:
# Kończymy program z ewentualnym komunikatem o błędzie.
# Kończymy program, ale najpierw sprzątamy po sobie: zwalniamy zasoby, których nie zwolni system operacyjny, zapisujemy dane, itp.
# 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 <nowiki>=</nowiki> int , size_t N <nowiki>=</nowiki> 100> class Stack {
 private:	
   T _rep[N];
   size_t _top;
 public:
   Stack():_top(0) {};
   void push(T val) {
     if(_top <nowiki>=</nowiki><nowiki>=</nowiki> N) {
       throw "pushing on top of the full stack";
     }
     _rep[_top++]<nowiki>=</nowiki>val;
   }
   T pop() {
     if(is_empty()) {
       throw "poping form an empty stack";
     }
     return _rep[--_top];
   }
   bool is_empty() const     {return (_top<nowiki>=</nowiki><nowiki>=</nowiki>0);} 
 };
 /* {mode13/code/stack_except.h}{stackexcept.h}*/
 
Polecenie <code>throw</code> 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 
<code>const char *</code>.  
Wykonanie programu

 main() {
   Stack<int,5> s;
   s.push(1);
   s.pop(); 
   s.pop(); /* tu będzie rzucony wyjątek */
   
   for(int i<nowiki>=</nowiki>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
<code>pop</code>. Komunikat, który się przy tym pojawia jest zależny
od implementacji. 

Wyjątki można łapać korzystając z bloku <code>try</code>.

 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<nowiki>=</nowiki>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 <code>try</code> umieszczamy instrukcje które mogą potencjalnie rzucić
wyjątek. Za blokiem <code>try</code> umieszczamy jedną lub więcej klauzul <code>catch</code>
które te wyjątki łapią. Wyjątek rzucony w bloku <code>try</code>  powoduje przekazanie
sterowania do pierwszej pasującej klauzuli <code>catch</code>. 

==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<nowiki>=</nowiki>0):val(i) {cerr<<"constructing "<<val<<"";}
   &nbsp;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ć? 
# Wyjątek przerwał wykonywanie funkcji <code>f()</code> i bloku <code>try</code>, sterowanie zostało przekazana do klauzuli <code>catch(int)</code>. 
# Przedtem  wywołane zostały destruktory obiektów <code>x</code> i <code>z</code>, czyli lokalnych obiektów w zasięgu bloku <code>try</code>. Ten proces nazywamy "zwijaniem stosu".
# Po wykonaniu klauzuli <code>catch</code> sterowanie zostało przekazane do następnego wyrażenia.
 
Klauzula <code>catch(...)</code> wyłapuje każdy wyjatek, jeśli np. pominiemy
klauzule <code>catch(int)</code>:

 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
<code>catch</code> 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ę <code>catch</code>:

 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 <code>abort()</code>, która
zakończyła program bez wywołania  destruktorów. Sciśle rzecz
biorąc, niezłapany wyjątek wywołuje funkcję <code>terminate()</code>, która z
kolei domyślnie wywołuje funkcję <code>abort()</code>. 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
<code>g++</code>, w przypadku niezłapania wyjątku destruktory obiektów nie są
wywoływane.

Domyślne zachowanie funkcji <code>terminate()</code> 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 <code>abort()</code>. Oznacza to, że funkcja
<code>new_terminate()</code> musi kończyć się wywołaniem <code>abort()</code> lub
<code>exit()</code>.

 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 <code>terminate()</code> (nie dotyczy
to już funkcji wywoływanych wewnątrz klauzuli <code>catch</code>).  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 {
   &nbsp;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 <code>X</code> jest wołany dwa razy. Po raz
pierwszy, podczas wychodzenia z pierwszego bloku <code>try</code>. Jest to
normalne wywołanie spowodowane wyjściem poza zakres. 
Destruktor rzuca wyjątek, który zostaje wyłapany poprzez
klauzulę <code>catch(int)</code> na końcu bloku. Drugi raz, destruktor jest
wołany jako część zwijania stosu po wyjątku rzuconym jawnie w drugim bloku
<code>try</code>. Mimo, że łapiemy wyjątki <code>int</code>, i tak w tej sytuacji
wywoływana jest funkcja <code>terminate()</code>, a w konsekwencji i
<code>abort()</code>. Jest to  jeden z powodów, dla których destruktory
nie powinny rzucać wyjątków. Funkcja <code>uncaught_exception()</code>
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&nbsp;[[##fig:exceptions|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 <code>catch</code> jest ważna, ponieważ klauzule są
sprawdzane po kolei, i pierwsza która pasuje zostanie wykonana.
Gdybyśmy więc podali kaluzulę <code>catch(Exception &e)</code> 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 <code>throw(...)</code> umieszana za
deklaracją listy argumentów funkcji np.:

 void no_throw(int) throw();
 
deklaruje, że funkcja <code>no_throw</code> nie rzuci żadnego wyjątku, natomiast

 void throw_std(int) throw(exception);
 
deklaruje, że funkcja <code>throw_std</code> 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 <code>f</code> proklamuje całemu światu, że może rzucać wyjątek
(poprzez brak deklaracji, że nie może), podobnie funkcja <code>g()</code>, 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 <code>const</code>: funkcja zadeklarowana jako <code>const</code> nie
może wołać funkcji, które <code>const</code> 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
<code>unexpected()</code>, która domyślnie wywołuje <code>abort()</code>. 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 <code>terminate()</code> możemy podstawić
własną funkcję <code>unexpected()</code>. Podobnie jak <code>terminate()</code> funkcja
<code>unexpected()</code> 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ż <code>f()</code>  rzuca <code>const char *</code>, a deklaruje tylko <code>int</code>-a,
powyższy program wywoła funkcję <code>unexpected()</code>, 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 <code>const char *</code> zostanie rzucony <code>int</code> i złapany przez
klauzulę <code>catch(...)</code>. Tak się stanie ponieważ <code>int</code> jest na
liście wyjątków funkcji <code>f()</code>. Gdyby nie był, to zostałaby wywołana
funkcja <code>terminate()</code>. Jeżeli jednak deklaracja wyjątków funkcji
<code>f()</code> zawierać będzie wyjatek <code>std::bad_exception</code>, to każdy
wyjątek rzucony przez <code>unexpected()</code> i nie znajdujący się na liście
zadeklarowanych wyjątków funkcji <code>f()</code> jest podmienieny na
<code>std::bad_exception()</code>:

 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<nowiki>=</nowiki>0;
   double s<nowiki>=</nowiki>0.0;
   for(int i<nowiki>=</nowiki>0;i<100000000;++i) {
     try {
     s+<nowiki>=</nowiki>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<nowiki>=</nowiki>0;
   double s<nowiki>=</nowiki>0.0;
   for(int i<nowiki>=</nowiki>0;i<100000000;++i)
     s+<nowiki>=</nowiki>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ę <code>f</code> 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.
  
{| border=1
|+ <span style="font-variant:small-caps">Uzupelnij tytul</span>
|- 
|  ||   1 nie rzucane wyjątki   ||  2 bez wyjątków  ||   3 rzucane wyjątki  ||  4 <tt>return</tt>
|-
| -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
<code>-finline-functions</code> powoduje skok predkości pomiędzy dwoma
ostatnimi wierszami w pierwszej kolumnie. Ten sam effekt można uzyskać
dodając do funkcji <code>scin</code> kwalifikator <code>inline</code>.

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.

==Kiedy rzucać wyjątki==

==Podsumowanie==