Trei tipuri de excepții în Java
Share
Erorile sunt interdicția utilizatorilor și programatorilor. Dezvoltatorii, evident, nu doresc ca programele lor să se încadreze la fiecare rând, iar utilizatorii sunt acum obișnuiți să aibă erori în programe, încât acceptă cu grație să plătească prețul pentru software care va avea aproape sigur cel puțin o eroare. Java este conceput pentru a oferi programatorului o șansă sportivă în proiectarea unei aplicații fără erori. Există excepții pe care programatorul le va cunoaște că sunt o posibilitate când o aplicație interacționează cu o resursă sau cu un utilizator și aceste excepții pot fi gestionate. Din păcate, există excepții pe care programatorul nu le poate controla sau pur și simplu trece cu vederea. Pe scurt, toate excepțiile nu sunt create egale și, prin urmare, există mai multe tipuri pentru care un programator să se gândească.
O excepție este un eveniment care face ca programul să nu poată curge în execuția prevăzută. Există trei tipuri de excepție - excepția verificată, eroarea și excepția de rulare.
Excepția verificată
Excepțiile verificate sunt excepții la care ar trebui să facă față o aplicație Java. De exemplu, Dacă o aplicație citește date dintr-un fișier, ar trebui să poată gestiona FileNotFoundException . La urma urmei, nu există nicio garanție că fișierul preconizat va fi acolo unde se presupune că se află. Orice s-ar putea întâmpla în sistemul de fișiere, despre care o aplicație nu ar avea niciun indiciu.
Pentru a face acest exemplu cu un pas mai departe. Să spunem că folosim FileReader clasa pentru a citi un fișier de caractere. Dacă aruncați o privire la definiția constructorului FileReader în aplicația Java, veți vedea semnarea metodei:
public FileReader (String fileName) aruncă FileNotFoundException După cum vedeți constructorul afirmă în mod specific că FileReader constructor poate arunca a FileNotFoundException. Acest lucru are sens, deoarece este foarte probabil că nume de fișier Șirul va fi greșit din când în când. Priviți următorul cod:
public static void main (String [] args) FileReader fileInput = null; // Deschideți fișierul de intrare fileInput = new FileReader ("Untitled.txt"); Sintactic, afirmațiile sunt corecte, dar acest cod nu va fi întocmit niciodată. Compilatorul cunoaște FileReader constructor poate arunca a FileNotFoundException și este de competența codului apelant să gestioneze această excepție. Există două opțiuni - în primul rând putem trece excepția din metoda noastră, specificând a aruncă clauza de asemenea:
public static void main (args String []) aruncă FileNotFoundException FileReader fileInput = null; // Deschideți fișierul de intrare fileInput = new FileReader ("Untitled.txt"); Sau ne putem descurca de fapt cu excepția:
public static void main (String [] args) FileReader fileInput = null; încercați // Deschideți fișierul de intrare fileInput = new FileReader ("Untitled.txt"); catch (FileNotFoundException ex) // spuneți utilizatorului să meargă să găsească fișierul Aplicațiile Java bine scrise ar trebui să poată face față excepțiilor verificate.
Erori
Al doilea tip de excepție este cunoscut sub numele de eroare. Când apare o excepție, JVM va crea un obiect de excepție. Aceste obiecte derivă toate din Dispensabil clasă. Dispensabil clasa are două subclase principale- Eroare și Excepție. Eroare clasa denumește o excepție cu care o aplicație nu este probabil să poată face față.
Aceste excepții sunt considerate rare. De exemplu, JVM s-ar putea să rămână fără resurse datorită faptului că hardware-ul nu poate face față tuturor proceselor cu care este ocupat. Este posibil ca aplicația să surprindă eroarea pentru a notifica utilizatorul, dar în mod obișnuit, aplicația va trebui să se închidă până când soluționarea problemei de bază.
Excepții de rulare
O excepție de rulare apare pur și simplu pentru că programatorul a făcut o greșeală. Ați scris codul, totul arată bine compilatorului și atunci când mergeți să rulați codul, acesta se încadrează, deoarece a încercat să acceseze un element dintr-un tablou care nu există sau o eroare de logică a cauzat o metodă să fie apelată cu o valoare nulă. Sau orice număr de greșeli pe care le poate face un programator. Dar este în regulă, observăm aceste excepții prin testare exhaustivă, nu?
