Modalitati clasice de tratare a erorilor

Vom prezenta notiunile legate de tratarea erorilor cu ajutorul unui exemplu, si anume, vom considera o clasa Vector pentru reprezentarea vectorilor de elemente intregi:

Considerand ca se aplica o tratare clasica a erorilor, functiile clasei Vector ar putea fi definite ca mai jos:
 

O functie confruntata cu o situatie de eroare, in cazul tratarii clasice, poate adopta una din urmatoarele optiuni:

• [1] terminarea fortata a programului: aceasta alternativa nu este tocmai o tratare a erorii. De multe ori o eroare nu este chiar atat de grava, iar programul poate si trebuie sa se "descurce" cu ea intr-un mod mai inteligent.
• [2] returnarea unei valori speciale pe post de "eroare".
• [3] returnarea unei valori valide, care insa poate implica coruperea starii programului. Un exemplu elocvent in acest sens il constituie secventa de mai jos:

 

int *p=new int[10]; p[20]=6;//rezultatul 'returnat' de aceasta          //expresie este 6, dar executia          //operatiei corupe starea heap-ului

• [4] apelul unei functii prevazute special pentru cazurile de eroare. Aceasta functie, la randul ei are de ales intre cele 3 alternative de mai sus.

Cu privire la alternativa [2] trebuie spus ca ea nu este intotdeauna usor de aplicat. Daca pentru functia Vector::find, de exemplu, valoarea -1 ca indicator de esec este satisfacatoare (este clar ca un indice de tablou nu poate fi negativ in mod normal), in schimb pentru Vector::operator[] si Vector::min ce valoare a tipului int ar putea fi considerata ca "iesita din comun"? Pentru asemenea situatii o solutie ar putea fi aceea ca, in loc de int, tipul returnat sa fie o structura compusa din rezultatul propriu-zis si un fanion de eroare.

Pe de alta parte, chiar si acolo unde este aplicabila, optiunea [2] implica necesitatea testarii de fiecare data a rezultatului executiei functiilor respective. Acest lucru poate duce usor la dublarea dimensiunii codului.

Alternativa [3] prezinta dezavantajul ca apelantul functiei in care a aparut eroarea poate sa nu "observe" ca s-a intamplat ceva. Astfel, multe functii din biblioteca standard C indica aparitia unei erori prin setarea variabilei globale errno. De cele mai multe ori, insa, in programe nu se testeaza valoarea lui errno suficient de sistematic incat sa se obtina o tratare consistenta a erorilor.

Tratarea erorilor cu ajutorul exceptiilor

Vom relua exemplul cu clasa Vector si vom rescrie functia Vector::operator[] astfel incat sa lucreze cu exceptii:

Mecanismul exceptiilor aduce ca noutate separarea explicita a secventelor de cod "normale" fata de cele de tratare a erorilor. In felul acesta programele devin mult mai clare, simplificandu-se cooperarea intre fragmente de program scrise separat.

Ideea fundamentala care sta la baza mecanismului exceptiilor este aceea ca daca o functie oarecare F1 se confrunta cu o situatie pe care nu o poate rezolva, ea va anunta acest lucru apelantului ei, prin emiterea unei asa-numite exceptii, "sperand" ca apelantul va putea (direct sau indirect) sa rezolve problema. O functie F2 care doreste sa rezolve o situatie de exceptie trebuie sa-si manifeste intentia de a capta exceptia emisa in situatia respectiva. Secventa de program care realizeaza captarea unei exceptii se numeste handler de exceptii.

C++ pune la dispozitie 3 constructii de baza pentru lucrul cu exceptii:

• instructiunea throw pentru emiterea exceptiilor;
• blocul catch pentru definirea handler-elor de exceptii;
• blocul try pentru delimitarea secventelor de cod sensibile la aparitia exceptiilor.

In exemplul propus s-a definit clasa Vector::ErrIndex pentru a reprezenta exceptiile emise la utilizarea unui indice eronat in contextul obiectelor de tip Vector. Se observa ca aceasta clasa nu contine nici un membru si, ca urmare, obiectele ei nu transmit nici o alta informatie decat simplul fapt ca, la o referire de forma v[i], unde v este de tip Vector, s-a utilizat o valoare eronata pentru i.

Instructiunea throw

Ca sintaxa, aceasta intructiune este asemanatoare cu return:
 
 

unde expresie_exceptie are ca rezultat un obiect apartinand unui tip ales de proiectant pentru reprezentarea exceptiilor.

Obs: exista si varianta simpla, fara argument a instructiunii throw. Rolul ei este de a retransmite o exceptie si va fi discutat in paragraful referitor la blocurile catch.

Presupunem pentru inceput ca instructiunea throw nu apare in interiorul unui bloc try. In acest caz putem spune ca throw si return sunt asemanatoare si d.p.d.v. al comportamentului, in sensul ca executia lui throw inseamna, printre altele:

• iesirea din functia curenta, cu tot ce presupune acest lucru: eliminarea din stiva a variabilelor locale ale functiei, deci executia distructorilor corespunzatori pentru variabilele de tip clasa, daca acestea exista;
• transmiterea catre apelant a unui rezultat, adica a obiectului generat de expresia din argument.

Intre instructiunile throw si return exista si deosebiri:

• In primul rand, iesirea dintr-o functie prin throw este considerata ca iesire "anormala" si acest lucru are mare importanta in contextul mecanismului de functionare a constructorilor/distructorilor.
• In al doilea rand, revenirea dintr-o functie prin emiterea unei exceptii nu se margineste doar la redarea controlului apelantului direct al functiei, ci presupune strabaterea stivei de apeluri in cautarea unui posibil handler pentru exceptia respectiva. Acest aspect va fi discutat in paragraful destinat descrierii blocurilor try-catch.

Sintaxa limbajului C++ permite specificarea in prototipul unei functii tipurile de exceptii pe care aceasta le poate emite, prin adaugarea unei clauze throw:
 
 

Clauza throw poate lipsi sau poate avea lista de tipuri de exceptii vida. Vom avea deci pentru specificarea unei functii urmatoarele posibilitati:

• tip_rez func(lista_par_form); //clauza throw absenta

• tip_rez func(lista_par_form) throw(); //lista tipurilor de exceptii   vida

• tip_rez func(lista_par_form) throw(tip_exp_1,. . .,tip_expn);

Clauza throw face parte din interfata (prototipul) unei functii. Prezenta ei aduce un plus de claritate pentru utilizatorii functiei respective, mai ales atunci cand ei nu au acces la definitia functiei.

Blocurile try-catch

Din punct de vedere sintactic un bloc try-catch are forma:

Un bloc try poate fi urmat de unul sau mai multe blocuri catch. Modul de functionare al unei asemenea constructii este urmatorul: daca in decursul desfasurarii secventei de operatii din blocul try este emisa o exceptie, fie direct (adica prin executia unui throw explicit), fie indirect (adica prin apelul unei functii care emite exceptia), secventa se intrerupe si se baleiaza lista de blocuri catch asociate pentru a-l detecta pe cel corespunzator tipului de exceptie emisa. Daca un astfel de bloc exista, se va lansa in executie secventa de tratare a exceptiei respective. Daca aceasta secventa nu trece printr-un return sau throw, la terminarea ei executia programului continua cu linia care urmeaza dupa ultimul bloc catch atasat blocului try curent (cea notata cu (*) in figura de mai sus).

Trebuie precizat ca un bloc catch poate avea si forma:

Un astfel de bloc capteaza exceptii de orice tip: este handler universal.

Daca nu exista nici un bloc catch corespunzator exceptiei emise, aceasta va fi propagata spre eventuale blocuri try-catch exterioare.

Este posibil ca o secventa catch sa execute la randul ei o comanda throw. Efectul in acest caz este intreruperea functiei curente prin emisia unei exceptii care va fi preluata de unul din apelantii functiei. Exceptia emisa dintr-un bloc catch poate fi aceeasi cu cea primita spre rezolvare (spunem ca are loc restransmisia exceptiei), sau o alta noua. Retransmisia unei exceptii se face cu ajutorul unei instructiuni throw fara argument.

Practic, un bloc catch poate fi asimilat cu o functie care are un singur parametru, de tipul celui specificat dupa cuvantul catch. Apelul unei asemenea functii se face automat, la aparitia unei exceptii de tip corespunzator in blocul try la care este atasat blocul catch respectiv.

Referitor la "drumul" parcurs de o exceptie din momentul emiterii sale si pana ajunge sa fie tratata, lucrurile stau astfel:

• [1]Stiva de apeluri se baleiaza dinspre varf spre baza in cautarea unui bloc try inconjurator in raport cu instructiunea throw emitatoare. Vom spune ca un bloc try este inconjurator (sau exterior) fata de o instructiune throw daca aceasta se gaseste chiar in interiorul secventei try respective sau se afla intr-o functie apelata (direct sau indirect) din secventa try.
• [2]Daca se gaseste un bloc try inconjurator, se cauta intre blocurile catch atasate unul care corespunde tipului exceptiei emise. Daca exista un astfel de bloc catch, acesta va capta exceptia. In caz contrar, exceptia este "propagata" mai departe, repetandu-se procesul de la pasul [1]. Daca se ajunge cu cautarea pana in functia main si nici aici nu exista un handler adecvat, se produce abandonul programului.
• [3]Daca exceptia este preluata de un handler si acesta nu o retransmite, exceptia este considerata ca tratata.

Cu ajutorul unor mici exemple vom ilustra mecanismul de functionare a blocurilor try-catch si a instructiunii throw.

Presupunem ca la un moment dat lantul de apeluri este main -> si_inca_una -> alta_functie -> o_functie si ca o_functie executa instructiunea throw. Se creaza o exceptie de tip O_exceptie, se iese din o_functie, revenindu-se in alta_functie. Aici se constata ca nu exista bloc try si ca urmare se iese din alta_functie ca si cum aici ar exista un throw, si se revine in si_inca_una. De data aceasta revenirea are loc in interiorul unui bloc try (cel notat cu 1). Se cauta printre ramurile sale catch si se gaseste cea cu parametru de tip O_exceptie. Daca exceptia se poate rezolva, dupa executia secventei catch programul continua cu blocul try urmator (cel notat cu 2).
Daca se ajunge la retransmisia exceptiei, atunci se iese din si_inca_una si se verifica daca apelul la aceasta functie nu se afla in interiorul unui bloc try din apelant (main, adica). Atentie deci: la executia unui throw din interiorul unui bloc catch nu se rebaleiaza lista curenta de handler-e si nici nu se trece la un bloc try-catch aflat "mai la vale" in aceeasi functie, chiar daca acesta din urma ar putea capta exceptia emisa (cum ar fi cazul blocului try 2 din exemplul de mai sus).
Exista si posibilitatea ca un bloc try-catch sa fie inclus in secventa try a unui alt bloc try-catch, ca in urmatorul exemplu:

In exemplul prezentat se observa ca blocul try-catch notat cu 2 nu va capta exceptii de tipul O_exceptie. Blocul try-catch notat cu 1 este considerat ca inconjurator pentru blocul 2 si deci, exceptia emisa de o_functie va ajunge sa fie tratata de handler-ul corespunzator atasat blocului 1.
In concluzie, se considera ca un bloc try este inconjurator pentru un throw daca secventa try

• contine in mod direct acel throw sau
• contine un bloc try-catch in care se afla acel throw sau
• contine radacina apelului la functia in care se afla acel throw.

Blocurile try si catch reprezinta si domenii de definitii de nume. Cu alte cuvinte, identificatorii definiti in interiorul acestor blocuri sunt vizibile si traiesc doar acolo. Exemplu:

Gruparea exceptiilor

Este posibil ca proiectantul sa-si defineasca o ierarhie de tipuri de exceptie. In acest caz unul si acelasi handler poate capta exceptii apartinand unor tipuri aflate in relatia clasa de baza-clasa derivata:

Atunci cand nu se doreste tratarea diferentiata a 2 tipuri de exceptii care deriva dintr-o baza comuna, se va scrie un handler care va avea ca parametru o exceptie de tipul clasei de baza. In acest context se pot exploata binefacerile mecanismului de functii virtuale, cu conditia ca tipul parametrului handler-ului sa fie referinta sau adresa la clasa de baza respectiva (cum ar fi MathErr& in exemplul de mai sus):

Un lucru important care trebuie specificat in legatura cu gruparea exceptiilor este acela ca daca intr-un bloc try-catch exista cel putin 2 handler-e pentru care tipurile exceptiilor sunt in relatia supertip-subtip sau exista handler-ul universal, atunci nu este indiferent in ce ordine plasam in program handler-ele respective. Aceasta restrictie deriva din faptul ca, la emiterea unei exceptii, cautarea unui catch corespunzator se face parcurgand lista de blocuri catch in ordinea textuala in care apar ele.
Regula generala este ca handler-ul corespunzator subtipului sa se scrie inaintea celui corespunzator supertipului (asa cum se vede in exemplul de mai sus), iar handler-ul universal, daca exista, sa fie ultimul din lista. Daca nu se respecta aceasta regula, se ajunge in situatia ca anumite handler-e nu vor fi niciodata accesate, ele fiind "mascate" de handler-ele situate inaintea lor si care vor capta toate exceptiile aparute.

Constructorii/distructorii in contextul tratarii exceptiilor
Intr-un paragraf anterior se facea afirmatia ca terminarea prin throw a unei functii este considerata ca "anormala" si ca lucrul acesta este semnificativ din punct de vedere al mecanismului de functionare a constructorilor/distructorilor.
Sa lamurim ce inseamna aceasta: daca la crearea unui obiect constructorul implicat se termina printr-un throw, la disparitia obiectului respectiv NU se va mai executa distructorul, deoarece se considera ca obiectul nu a fost initializat complet.
Pe de alta parte insa (si aici e salvarea), daca intre membrii obiectului se afla alte obiecte si acestea au apucat sa fie initializate corect, pentru ele se vor executa distructorii aferenti.
Consecintele acestui mod de functionare se "simt" atunci cand un constructor apuca sa realizeze alocarea uneia sau a mai multor resurse (de ex. alocari din heap sau deschideri de fisiere), dupa care, dintr-un motiv oarecare, se termina prin throw. Distructorul, care ar trebui in mod normal sa elibereze resursele respective, nu se va executa la disparitia obiectului, deci resursele raman alocate. Exemplu:
 

Portita de scapare pentru aceste situatii consta in a realiza alocarea de resurse prin intermediul unor obiecte, asa ca in urmatoarea secventa:
 

Politica aplicata prin solutia de mai sus este cunoscuta sub denumirea de "alocarea resurselor prin initializare".
Acest concept poate fi sintetizat astfel: fie o clasa de forma data mai jos:

Presupunem ca la crearea unui obiect al acestei clase constructorul reuseste sa execute corect alocarea a k resurse (1<= k <n), dupa care esueaza la tentativa de alocare a resursei k+1. In acest caz, la disparitia obiectului respectiv nu se va mai executa distructorul, deci cele k resurse raman alocate. Pentru a rezolva problema trebuie ca tipurile tip_i sa fie clase, constituite dupa modelul clasei MemPtr. Atunci, desi distructorul ~o_clasa nu se executa, totusi distructorii obiectelor resursa_i care au fost create corect se vor executa, ceea ce asigura eliberarea resurselor respective. Astfel se explica denumirea de "alocare prin initializare", si anume alocarea unei resurse se realizeaza de fapt prin initializarea unui obiect resursa_i:

Tema
1.Se cere sa se definesca o clasa Queue care modeleaza functionarea unei cozi FIFO cu elemente de tip char. Dimensiunea cozii este limitata si se specifica la creare. Operatiile care se pot aplica asupra cozii sunt:

• Put(char) pentru introducerea caracterului dat ca parametru;
• char Get() pentru extragerea primului caracter (cel introdus cel mai devreme).

2.Se cere sa se defineasca o clasa Files care sa modeleze lucrul cu fisiere de text, folosindu-se tipul clasic FILE*. Constructorul clasei va realiza deschiderea fisierului, iar distructorul va realiza inchiderea. Problema va fi prezentata in 2 variante: cu si fara aplicarea principiului de "alocare prin initializare", urmarindu-se modul de executie a constructorilor si distructorilor. In constructor se va simula o situatie de eroare oarecare dupa ce s-a deschis fisierul.
Ca metode pentru clasa Files, se vor prevedea minimum:

• char *getline(): citeste o linie intr-un buffer si returneaza adresa bufferului;
• int eof(): returneaza 1 daca s-a atins sfarsitul fisierului si 0 in caz contrar.

Bibliografie

[Bol98] W.R. Bolton - "Free Course Pamphlets", http://www.mindspring.com/~wrba/frepam/index.htm (legatura pe 'CPPTHROW')

[Gre99] C. Green - "Cliff's Teaching Info and Technical Resources", http://www.halcyon.com/cliffg/uwteach/index.html (legatura pe 'C++ Programming: Intermediate')

[Str91] B. Stroustrup  - "The C++ programming language",  AT&T, 1991