Paradigme de Programare Laboratorul 4

Laboratorul 4
4.1. Excepii

Excepiile sunt de fapt erori care apar la rularea aplicaiei (n timpul execuiei, nu la compilare). Folosind sistemul de control al excepiilor oferit de Java se pot trata astfel erorile ce pot aprea la execuie. n alte limbaje de programare anumite coduri de eroare erau returnate de unele metode a cror execuie eua, iar aceste coduri trebuiau verificate manual de fiecare dat cnd o astfel de metod era apelat. Aceast abordare era dificil dar i predispus la provocarea erorilor n scrierea codului. Sistemul oferit de Java permite definirea unui bloc de cod (exception handler) care s fie executat atunci cnd apare o eroare. Nu mai este necesar astfel verificarea anumitor coduri de eroare. n java, excepiile sunt reprezentate de clase i toate sunt extinse direct sau indirect din clasa Throwable. Asta nseamn c atunci cnd o excepie apare n execuia codului, o astfel de clas este generat. Exist dou clase extinse direct din Throwable: Error Reprezint excepii legate de erori ce apar chiar n maina virtual Java i nu n codul scris de noi. Aceste tipuri de erori nu sunt tratate de aplicaiile noastre. Exception Reprezint erori ce rezult din execuia codului scris de noi (ex: mprire la 0, indeci n afara limitelor sau erori la accesarea unor fiiere). Aplicaiile trebuie s trateze corespunztor erori de acest fel. O subclas important este RuntimeException care reprezint diverse erori ce pot aprea la execuie. Sistemul de tratare a erorilor din Java implic folosirea a 5 cuvinte cheie: try, catch, throw, throws i finally. Blocul de cod monitorizat n vederea prinderii i tratrii erorilor este ncadrat ntre cuvintele cheie try i catch. Dac o eroare apare n acest bloc de cod, o excepie este generat (aruncat thrown). Aceste excepii sunt prinse n blocurile catch i tratate dup dorin. Excepiile generate de sistem sunt generate i aruncate automat. Pentru a genera manual o excepie n urma unei stri pe care o considerm eronat, folosim cuvntul cheie throw. n cazurile n care o excepie este generat i nu este captat n corpul metodei curente, atunci metoda trebuie s specifice explicit c poate genera o anume excepie prin cuvntul cheie throws. Poriunile de cod care trebuie executate obligatoriu indiferent dac se genereaz sau nu o excepie n blocul try-catch sunt ncadrate ntr-un bloc finally. 4.1.1. Folosirea blocului try/catch Blocul try/catch st la baza sistemului de tratare a erorilor. O poriune de cod nu poate fi monitorizat pentru tratarea excepiilor fr a fi inclus ntr-un astfel de bloc. Forma general:
try { //blocul ce trebuie monitorizat } catch (ExceptionTypeA e) { //tratarea pentru o excepie de tipul ExceptionTypeA

Paradigme de Programare Laboratorul 4

} catch (ExcpetionTypeB e) { //tratarea pentru o excepie de tipul ExcpetionTypeB }

Observm c pot fi mai multe blocuri catch asociate aceluiai boc try, iar dac o excepie este aruncat n blocul try aceasta este prins n blocul catch corespunztor. Blocul catch ce urmeaz s trateze excepia se alege n funcie de tipul excepiei asociat cu acest catch astfel: dac un tip de excepie specificat de o instruciune catch se potrivete cu tipul excepiei ce trebuie tratate, atunci blocul acelei instruciuni catch se execut iar eventualele blocuri catch care urmeaz sunt ignorate. Excepia generat ce trebuie tratat se obine prin parametrul instruciunii catch. Un aspect important de remarcat este c unul din blocurile cath se execut numai n cazul n care o excepie este generat n corpul try corespunztor i tipul acestei excepii se potrivete cu cel specificat de instruciunea catch respectiv. Dac nici o excepie nu este generat execuia decurge normal srind peste blocurile catch. Exemplu
public class ExempluTryCatch { public static void main(String[] args) { int values[] = new int[10]; try { System.out.println("Inainte de generare exceptie"); values[11] = 10; // index gresit System.out.println("dupa generare executie. Nu se va executa!"); } catch (ArrayIndexOutOfBoundsException ex) { System.out.println("prindere exceptie"); } System.out.println("cod dupa bloc catch"); } }

Ieirea n urma execuiei este urmtoarea:

Inainte de generare exceptie prindere exceptie cod dupa bloc catch

Observm c atunci cnd ncercm s accesm o poziie greit dintr-un vector, o excepie este aruncat n afara blocului try, execuia acestui bloc se ntrerupe iar controlul este preluat de blocul catch. Aspectul important atunci cnd o excepie este generat este c o instruciune catch nu este apelat ci pur i simplu firul execuiei este transferat acestui bloc. Acest lucru nseamn c atunci cnd codul catch i termin execuia firul execuiei nu revine n blocul try acolo unde s-a generat execuia ci trece la prima instruciune dup blocurile catch. ntregul cod cuprins ntr-un bloc catch este monitorizat pentru captarea excepiilor, inclusiv codul din metodele apelate din acest bloc try:
public class ExempluTryCatch { public static void testMethod() { int values[] = new int[10]; values[11] = 10; // index gresit }

Paradigme de Programare Laboratorul 4

public static void main(String[] args) { try { System.out.println("Inainte de generare exceptie"); testMethod(); System.out.println("dupa generare executie. Nu se va executa!"); } catch (ArrayIndexOutOfBoundsException ex) { System.out.println("prindere exceptie"); } System.out.println("cod dupa bloc catch"); } }

n urma rulrii programului de test obinem acelai rezultat. Observm c excepia generat n cadrul metodei de test nu este prins i tratat prin urmare aceasta va fi prins n blocul try/catch din metoda apelatoare. Dac o excepie este generat i nu este tratat nicieri, atunci nsi execuia programului va fi ntrerupt, execuia fiind prins de maina virtual. Un astfel de comportament al aplicaiei n cazul generrii excepiilor poate fi util doar n cazul rulrii pentru test sau pentru debug. Este uor de neles de ce trebuie s prindem i s tratm corespunztor excepiile. Dac codul care provoac generarea este cuprins ntr-un bloc try/catch dar nici o instruciune catch nu specific un tip de excepie potrivit cu cel al excepiei generate, atunci acea excepie este aruncat mai departe, urmnd s fie prins de un alt eventual bloc try/catch sau dac nu de maina virtual. 4.1.2. Excepiile i subclasele Atunci cnd se stabilete ce bloc catch trebuie s trateze o anumit excepie, conteaz potrivirea dintre tipul acesteia i tipul specificat de instruciunea catch. Aceast potrivire ine cont i de ierarhia de clase ce reprezint excepiile. Astfel, o instruciune catch ce specific tipul Throwable va capta orice tip de excepie. Putem astfel s tratm n mod explicit unele excepii iar restul s le prindem pe toate i s oferim o tratare generic. Trebuie avut n vedere ns ordinea n care specificm aceste tipuri: un subtip trebuie specificat naintea oricrui tip de baz al su, altfel codul lor nu va mai putea fi executat niciodat.
public class ExempluSubclase { public static void main(String[] args) { int values[] = { 0, 1, 2 }; for (int i = 0; i <= 3; i++) { try { int nr = 10 / values[i]; System.out.println("rezultat : " + nr); } catch (ArrayIndexOutOfBoundsException ex) { System.out.println("exceptie : index gresit"); } catch (Throwable ex) { System.out.println("o exceptie a aparut : " + ex.getMessage()); } } } }

Observm c excepia provocat de indexul greit este tratat n mod expres, iar celelalte sunt prinse pentru a permite continuarea execuiei codului. 3

Paradigme de Programare Laboratorul 4 4.1.3. Generarea manual a excepiilor n exemplele anterioare am observat tratarea excepiilor generate automat de ctre maina virtual. Folosind instruciunea throw excepiile pot fi provocate i manual. Parametrul instruciunii throw trebuie s fie un obiect de tipul unei subclase Thowable.
public class ExempluThrow { public static void main(String[] args) { try { System.out.println("inainte de throw"); throw new Exception("exceptie generata manual"); } catch(Exception ex) { System.out.println("exceptie : " + ex.getMessage()); } } }

Excepia generat trebuie creat (new). Exist posibilitatea s se arunce mai departe o excepie deja existent. Un astfel de comportament ar fi de dorit atunci cnd dorim s tratm aceeai excepie la mai multe niveluri logice, fiecare ocupndu-se de un anumit aspect. 4.1.4. Clasa Throwable ntr-un bloc catch tratm un anumit tip de eroare n funcie de informaiile ce se pot obine din obiectul excepie primit ca parametru. Toate excepiile sunt subclase Thowable i ofer urmtoarele metode utile:

printStackTrace(): afieaz apelurile succesive care au dus la codul cea generat excepia getMessage(): descriere a excepiei toString(): returneaz un obiect String ce conine descrierea excepiei

4.1.5. Blocul Finally Atunci cnd se dorete ca anumite poriuni de cod s se execute indiferent dac blocul try s-a executat normal sau a generat o excepie, folosim blocul finally:
public class ExempluFinally { public static void main(String[] args) { int values[] = { 0, 1, 2 }; for (int i = 0; i <= 3; i++) { try { int nr = 10 / values[i]; System.out.println("rezultat : " + nr); } catch (ArrayIndexOutOfBoundsException ex) { System.out.println("exceptie : index gresit"); } catch (Throwable ex) { System.out.println("o exceptie a aparut : " + ex.getMessage()); } finally { System.out.println("finally bloc pt i = " + i); } } } }

Paradigme de Programare Laboratorul 4 Ieirea n urma rulrii ne arat c blocul finally se execut indiferent de modul n care blocul try i-a terminat execuia. 4.1.6. Clauza throws Dac o metod conine cod ce ar putea genera o excepie i totui n cadrul metodei nu exist un bloc try/catch care s prind acea excepie, atunci acea metod trebuie s specifice prin clauza throws c poate genera acea excepie. Totui nu se supun acestei reguli excepiile care sunt subclase ale claselor Error i RuntimeExcepion. ncercarea de a omite clauza throws cu o list corespunztoare de excepii pe care metoda le poate genera va rezulta ntr-o eroare la compilare. Metoda care va apela aceast metod va fi obligat la rndul ei s prind i s trateze excepia sau s specifice prin clauza throws ca poate genera mai departe excepia respectiv.
import java.io.IOException; public class TestThrows { public static char testMethod() throws IOException { System.out.println("introiduceti un caracter"); return (char) System.in.read(); } public static void main(String[] args) { try { char ch; ch = testMethod(); System.out.println("ch : " + ch); } catch (IOException e) { e.printStackTrace(); } } }

Paradigme de Programare Laboratorul 4

4.2.

Generice

Scopul introducerii tipurilor generice n limbajul Java a fost cel de a ajuta la descoperirea mai eficient a bug-urilor. Unele bug-uri sunt mai uor de depistat, de exemplu cele descoperite la compilare indic imediat neregulile din cod. Tipurile generice ajut la scrierea unui cod mai sigur tocmai prin determinarea unor bug-uri s fie detectabile la compilare. Tipurile generice sunt intens folosite de clasele care implementeaz colecii de date. O astfel de clas, fr a folosi tipuri generice, ar controla o colecie de obiecte de tip Object. Adugarea de obiecte de orice tip (mai puin cele primare) se poate face fr probleme. Probleme apar atunci cnd avem nevoie s extragem un obiect de un anumit tip dintr-o colecie de date. Obiectul obinut este de tip Object, iar noi trebuie s facem o conversie adecvat explicit. Aici este punctul unde pot aprea problemele. Folosind o conversie explicit la un tip pe care l tim noi c este cel corect, nu permite compilatorului n nici un fel s verifice dac conversia este una permis. Dac un anumit obiect extras dintr-o colecie de date nu este de tipul ateptat, atunci ncercarea de conversie va genera o excepie n tipul execuiei. Exemplu fr generics: Lum ca exemplu o clas ce conine un obiect de un anumit tip i face anumite prelucrri asupra acelui obiect. Cum dorim ca funcionalitatea oferit de aceast clas s o putem folosi asupra unor obiecte de orice tip, vom folosi o instan la un obiect de tip Object. Astfel de clase ce implementeaz funcionaliti ce se pot aplica unor obiecte de diverse tipuri sunt des ntlnite i utile (colecii de date, stive, cozi, liste) i este lesne de neles c nu dorim s facem cte o nou implementare pentru fiecare tip de obiect cu care avem nevoie la un moment dat s populm o astfel de clas. Pentru simplitate exemplul nostru va fi o clas ce va conine un singur obiect.
package work; public class Container { private Object element; public void setElement(Object element) { this.element = element; } public Object getElement() { return element; } }

Pentru a testa clasa scris vom seta un element i-l vom extrage. Observm c valoarea ntreag pe care o setm este o valoare primitiv (nu este o referin la un obiect, deci n mod normal nu poate fi convertit la tipul Object pe care metoda l ateapt). O convertire implicit este realizat de ctre compilator de la primitivul int la clasa ce nglobeaz un int: Integer. Cnd extragem elementul obinem un obiect Object pe care l convertim la tipul Integer (tim c este de acest tip) iar convertirea la tipul primitiv int al obiectului val se face implicit. Aceste convertiri implicite se numesc boxing/unboxing.
package work; public class ContainerTest {

Paradigme de Programare Laboratorul 4

public static void main(String[] args) { Container container = new Container(); container.setElement(10); int val =(Integer) container.getElement(); System.out.println("value : " + val); } }

Observm ca punctul vulnerabil al codului este momentul cnd extragem valoarea i o convertim la acel tip pe care tim noi c l-am folosit cnd am introdus variabila n Container. ntr-o aplicaie real cu un grad mai ridicat de complexitate exist posibilitatea s nu mai tim tipul real al obiectului extras sau ce tip de obiect trebuie introdus n container. S ncercm de exemplu n aplicaia noastr de test s introducem un element de tip String:
container.setElement("10");

Observm c la compilare nu suntem avertizai n nici un fel, iar dac vom rula din nou aplicaia vom obine o excepie:
Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer at work.ContainerTest.main(ContainerTest.java:10)

4.2.1. Tipuri generice Pentru declararea unui tip generic se folosete o variabil de tip, numit T. Aceast variabil de tip poate fi folosit oriunde n cadrul clasei i peste tot va avea nelesul tipului ce va fi dat ca parametru la instanierea clasei. Dac iniial, n exemplul nostru, foloseam tipul Object pentru a putea adapta implementarea la orice tip de obiecte, acum vom folosi tipul T ce va putea nlocui orice tip. Clasa noastr, folosind generice se va transforma astfel:
package work; public class Container<T> { private T element; public void setElement(T element) { this.element = element; } public T getElement() { return element; } }

Folosirea clasei se modific prin adugarea tipului dorit ca parametru. Folosirea unui tip generic se mai numete i invocare a unui tip parametrizat.
Container<Integer> container = new Container<Integer>();

Aplicaia de test a tipului se modific astfel: 7

Paradigme de Programare Laboratorul 4

package work; public class ContainerTest { public static void main(String[] args) { Container<Integer> container = new Container<Integer>(); container.setElement(10); int val = container.getElement(); System.out.println("value : " + val); } }

Observm c la extragerea elementului nu mai este necesar nici o conversie, deoarece metoda returneaz acum un obiect de tipul dat ca parametru (Integer) i nu Object. Problema tipului returnat este astfel rezolvat, o ncercare de a converti obiectul returnat la un tip incompatibil va genera o eroare de compilare corespunztoare. Mai observm de asemenea c la setarea elementului, metoda ateapt un obiect de tipul Integer, iar dac ncercm din nou s setm o variabil String, vom obine de aceast dat o eroare la compilare. Pe lng depistarea acestor greeli n timpul compilrii, observm c tipurile generice mai aduc unele avantaje: codul este mai lizibil i mai uor de neles, iar cnd folosim cod scris de altcineva este uor de observat ce tipuri putem folosi atunci cnd lucrm cu colecii de date sau altfel de implementri comune. Tehnica tipurilor generice se poate aplica att n cazul claselor ct i n cazul interfeelor. Un tip generic poate avea mai muli parametri de tip. De exemplu clasa din exemplul anterior s-ar declara astfel dac ar avea 2 parametri de tip: Container<T,U>. Prin convenie, parametrii de tip se numesc ncepnd cu litera T (Type). 4.2.2. Metode generice Parametrii de tip pot fi aplicai i metodelor (inclusiv constructorilor). Acestea se vor numi metode generice (constructori generici). Tehnica este similar cu cea de la tipurile generice, dect c scopul parametrilor de tip se rezum la metoda (constructorul) n care acetia au fost declarai.
package work; public class GenericMethod { public static <U> void testMethod(U u) { System.out.println(u.getClass().getName()); } public static void main(String[] args) { GenericMethod.<String>testMethod("test"); GenericMethod.testMethod(10); } }

n aceast clas putem vedea un exemplu de metod generic. La primul apel observm ca se specific tipul dorit, dar acest lucru nu este obligatoriu, deoarece compilatorul poate deduce singur 8

Paradigme de Programare Laboratorul 4 tipul necesar (type inference). La al doilea apel observm c nu mai specificm tipul dorit, iar dac rulm testul vom vedea c tipul dedus este Integer (clasa n care se nglobeaz un tip primitiv int). 4.2.3. Restricionarea parametrilor de tip Pn acum am observat c atunci cnd folosim generice nu exist nici un fel de restricionare n ceea ce privete parametrii de tip, n sensul c la invocarea tipurilor parametrizate putem folosi orice fel de tip. Pot aprea totui situaii cnd dorim ca o clas s se ocupe numai cu un anumit tip de obiecte. Acesta nseamn c dorim s restricionm parametrii de tip numai la tipuri care extind anumite clase i/sau implementeaz anumite interfee. n acest scop se folosete cuvntul cheie extends, dar sensul su este unul general, adic se refer att la extinderea de clase ct i la implementarea de interfee. De exemplu dac dorim ca exemplul anterior Container s se ocupe numai de valori numerice, atunci folosim pentru restricionare clasa Number, care este clasa de baz pentru toate clasele ce nglobeaz o valoare primitiv numeric (cum este Integer pentru int). Clasa devine astfel:
package work; public class Container<T extends Number> { private T element; public void setElement(T element) { this.element = element; } public T getElement() { return element; } }

n aplicaia de test putem folosi acum numai tipuri numerice:

package work; public class ContainerTest { public static void main(String[] args) { Container<Integer> intContainer = new Container<Integer>(); intContainer.setElement(10); int intVal = intContainer.getElement(); System.out.println("int value : " + intVal); Container<Float> floatContainer = new Container<Float>(); floatContainer.setElement(10.5f); float floatVal = floatContainer.getElement(); System.out.println("float value : " + floatVal); } }

Dac vom ncerca s instaniem tipul parametrizat cu un tip care nu extinde Number, String de exemplu, vom obine o eroare la compilare: 9

Paradigme de Programare Laboratorul 4

Exception in thread "main" java.lang.Error: Unresolved compilation problems: Bound mismatch: The type String is not a valid substitute for the bounded parameter <T extends Number> of the type Container<T>

4.2.4. Relaiile ntre tipurile generice n cazul claselor obinuite exist o relaie ntre clasele de baz i clasele care le extind. n exemplul anterior am folosit clasa Integer care extinde Number. Putem spune c Integer este un Number i oriunde trebuie s oferim o instan de tipul Number putem oferi un obiect Integer cu succes. Cu alte cuvinte o subclas specializeaz clasa sa de baz dar poate fi folosit la nevoie doar ca o instan a clasei de baz. n cazul tipurilor generice situaia st un pic diferit. Dac un obiect Integer este i un obiect Number, un obiect Container<Integer> nu este i un obiect Container<Number>. Dei pare neateptat, aceast idee are totui sens. Dac un obiect Integer este un obiect Number cu nite proprieti suplimentare i poate deci nlocui cu succes un obiect Number, un obiect de tip Container<Integer> controleaz un obiect Integer n mod special, i nu se poate asuma faptul c poate controla cu succes orice obiect de tip Number. Dac Container<Integer> i Container<Float> nu sunt subtipuri ale tipului Container<Number>, exist totui un mod de a referenia cele dou tipuri printr-o singur variabil:
Container<? extends Number> someContainer; someContainer = intContainer; someContainer = floatContainer;

Observm folosirea caracterului ? (wildcard) care substitue orice tip care extinde Number.

10

Paradigme de Programare Laboratorul 4

4.3.

Colecii

Denumirea de Collection sau Container se refer n general la un simplu obiect care grupeaz mai multe elemente i care ajut la salvarea, manipularea i transmiterea acelui grup de elemente. Necesitatea lucrului cu colecii de date este des ntlnit n programarea aplicaiilor, fapt pentru care limbajul Java ofer o arhitectur comun de reprezentare i manipulare a coleciilor de date. Aceast arhitectur se numete collection framework. Un astfel de framework trebuie s conin n general urmtoarele pari:

Interfee: tipuri abstracte de reprezentare a coleciilor. Ajut la manipularea coleciilor n mod independent de implementrile lor i formeaz de regul ierarhii. Implementri: implementrile concrete ale reprezentrilor abstracte menionate anterior Algoritmi: implementri ale unor procesri comune aplicate coleciilor, cum ar fi sortri i cutri. Aceti algoritmi sunt polimorfici: pot fi aplicai diferitelor implementri ale reprezentrilor abstracte.

4.3.1. Interfeele Observm mai jos ierarhia interfeelor din Collection Framework

Figura 4-1- Ierarhia interfeelor din Collection Framework

O observaie important este faptul c toate interfeele din aceast ierarhie sunt generice.

Collection: reprezentarea abstract a unui grup de obiecte numite elemente.

Operaii de baz: numrul de elemente (size, isEmpty), existena unui element n colecie (contains), adugare i eliminare de elemente (add, remove) i oferirea unui iterator (ietrator). Parcurgerea elementelor: se pot folosi dou moduri pentru a parcurge valorile unei colecii: folosind instruciunea for-each sau folosind un iterator. Instruciunea for-each ajut la traversarea valorilor dintr-o colecie sau dintr-un array:
for (Object elem : collection) { // proceseaz elementul curent }

Un iterator este un obiect ce implementeaz metodele interfeei Iterator: hasNext, next i remove. 11

Paradigme de Programare Laboratorul 4 Lucrul cu grupuri ntregi de valori: containsAll, addAll, removeAll, retainAll, clear.

Set: colecie care nu poate conine valori duplicate. List (secven): o colecie ordonat ce poate conine i valori duplicate. Suplimentar fa de Collection, List ofer unele faciliti: acces poziional (get(int index), set(int index, E element)), cutare (indexOf, lastIndexOf), Iteration, interfa care extinde Interator (hasPrevious, previous, nextIndex, previousIndex, set, add). Queue: colecie ce reine elementele nainte de a fi procesate.

Operaiile de baz: add i offer (adaug un element, n caz de depire a capacitii prima metod genereaz o excepie iar a doua returneaz false), remove i poll (terg i returnez din coad primul element, n caz c nu exist nici un element, prima metod genereaz o excepie iar a doua returneaz null), element i peek (acioneaz la fel ca precedentele operaii fr s tearg elementul din coad). Datorit faptului c peek i poll returneaz valoarea null cu un anumit sens, implementrile interfeei Queue nu permit n general inserarea elementelor nule.

Map: un obiect care mapeaz chei i valori. Nu poate conine chei duplicate.

Operaiile de baz: V put(K key, V value), V get(Object key), V remove(Object key), containsKey, containsValue. Un Map poate fi foolosit ca o colecie prin colecii pe care l ofer: keySet, values, entrySet. Cheile fiind unice, observm c prima i ultima colecie sunt Set-uri. Interfaa Entry definit n cadrul interfeei Map ofer urmtoarele metode: getKey, getValue, setValue. 4.3.2. Implementrile oferite Iat un tabel cu implementrile cu scop general oferite n Framework Collection, ct i tipul de implementare: Interfa Set List Map Hash Table HashSet ArrayList HashMap TreeMap Array redimensionabil Arbore TreeSet LinkedList LinkedHashMap List nlnuit Hash table cu list nlmuit LinkedHashSet

12

Paradigme de Programare Laboratorul 4

4.4.

Tem

Concepei o interfa Stack care s abstractizeze funcionarea unei stive. Oferii i o implementare default a acestei abstractizri. Pentru a putea folosi aceast stiv cu orice tipuri de date folosii tipurile generice. Definii mai nti o interfa Stack care s conin urmtoarele metode: isEmpty, isFull: dou metode prin care se testeaz limitele capacitii stivei push / offer: se introduce un element n stiv. Dac stiva este plin, prima metod va genera excepia StackFullExcepion, iar a doua va returna valoarea logic false. pop / poll: se extrage un element din stiv. Dac stiva este goal, prima metod va genera excepia StackEmptyException, iar a doua va returna valoarea null. peek / element: se obine valoarea din vrful stivei fr ca aceasta s fie tears din stiv. n mod similar se genereaz StackEmptyExcepion sau se returneaz null. Avnd n vedere c atunci cnd se obin valori din stiv se folosete null cu un sens anume, vom interzice introducerea valorilor null n stiv, o astfel de tentativ fiind semnalat printr-o excepie StackInvalidArgumentException. Pentru definirea tipurilor de excepii extindei clasa Exception i definii metodele toString i getMessage. Definii o clas care s implementeze interfaa Stack. Pentru reinerea intern a valorilor folosii un array (putei numi clasa ArrayStack). Clasa va avea un constructor prin care se va specifica capacitatea stivei. Pentru a putea folosi stiva cu diverse tipuri de obiecte, folosii n implementarea interfeei i a clasei tipurile generice.

13