Tipuri de excepții

1. Tipuri de excepții

Toate excepțiile sunt împărțite în 4 tipuri, care sunt de fapt clase care se moștenesc unele pe altele.

Throwableclasă

Clasa de bază pentru toate excepțiile este Throwableclasa. Clasa Throwableconține codul care scrie stiva de apeluri curentă (urma stivă a metodei curente) într-o matrice. Vom afla ce este o urmă de stivă puțin mai târziu.

Operatorul de aruncare poate accepta doar un obiect care derivă din Throwableclasă. Și, deși teoretic poți scrie cod ca throw new Throwable();, nimeni nu face asta de obicei. Scopul principal al Throwableclasei este de a avea o singură clasă părinte pentru toate excepțiile.

Errorclasă

Următoarea clasă de excepție este Errorclasa, care moștenește direct Throwableclasa. Mașina Java creează obiecte ale Errorclasei (și descendenții acesteia) atunci când au apărut probleme serioase . De exemplu, o defecțiune hardware, memorie insuficientă etc.

De obicei, ca programator, nu poți face nimic într-o situație în care o astfel de eroare (de tipul pentru care Errorar trebui aruncat) a apărut în program: aceste erori sunt prea grave. Tot ce puteți face este să notificați utilizatorul că programul se blochează și/sau să scrieți toate informațiile cunoscute despre eroare în jurnalul programului.

Exceptionclasă

Clasele Exceptionși RuntimeExceptionsunt pentru erori obișnuite care apar în operarea multor metode. Scopul fiecărei excepții aruncate este să fie prins de un catchbloc care știe să o gestioneze corect.

Atunci când o metodă nu își poate finaliza activitatea dintr-un motiv oarecare, ar trebui să notifice imediat metoda de apelare, lansând o excepție de tipul adecvat.

Cu alte cuvinte, dacă o variabilă este egală cu null, metoda va arunca un NullPointerException. Dacă argumentele incorecte au fost transmise metodei, aceasta va arunca un InvalidArgumentException. Dacă metoda se împarte accidental la zero, va arunca un ArithmeticException.

RuntimeExceptionclasă

RuntimeExceptionssunt un subset al Exceptions. Am putea spune chiar că RuntimeExceptioneste o versiune ușoară a excepțiilor obișnuite ( Exception) — sunt impuse mai puține cerințe și restricții pentru astfel de excepții

Veți învăța diferența dintre Exceptionși RuntimeExceptionmai târziu.

2. Throws: excepții verificate

Toate excepțiile Java se încadrează în 2 categorii: bifate și nebifate .

Toate excepțiile care moștenesc RuntimeExceptionsau Errorsunt considerate excepții neverificate . Toate celelalte sunt excepții bifate .

Care este principala diferență dintre excepțiile bifate și neverificate ?

Există cerințe suplimentare impuse excepțiilor verificate . În linii mari, acestea sunt acestea:

Cerința 1

Dacă o metodă aruncă o excepție bifată , trebuie să indice tipul de excepție în semnătura sa . În acest fel, fiecare metodă care o apelează este conștientă de faptul că această „excepție semnificativă” ar putea apărea în ea.

Indicați excepțiile bifate după parametrii metodei după throwscuvântul cheie (nu utilizați throwcuvântul cheie din greșeală). Arata cam asa:

type method (parameters) throws exception

Exemplu:

public void calculate(int n) throws Exception
{
   if (n == 0)
      throw new Exception("n is null!");
}

public void calculate(n)
{
   if (n == 0)
      throw new RuntimeException("n is null!");
}

În exemplul din dreapta, codul nostru aruncă o excepție nebifată - nu este necesară nicio acțiune suplimentară. În exemplul din stânga, metoda aruncă o excepție bifatăthrows , astfel încât cuvântul cheie este adăugat la semnătura metodei împreună cu tipul excepției.

Dacă o metodă se așteaptă să arunce mai multe excepții bifate , toate acestea trebuie specificate după throwscuvântul cheie, separate prin virgule. Ordinea nu este importantă. Exemplu:

public void calculate(int n) throws Exception, IOException
{
   if (n == 0)
      throw new Exception("n is null!");
   if (n == 1)
      throw new IOException("n is 1");
}

Cerința 2

Dacă apelați o metodă care a verificat excepții în semnătură, nu puteți ignora faptul că le aruncă.

Trebuie fie să prindeți toate astfel de excepții adăugând catchblocuri pentru fiecare, fie adăugându-le la o throwsclauză pentru metoda dvs.

Este ca și cum am spune: „ Aceste excepții sunt atât de importante încât trebuie să le prindem. Și dacă nu știm cum să le gestionăm, atunci oricine ar putea apela metoda noastră trebuie să fie anunțat că astfel de excepții pot apărea în ea.

Exemplu:

Imaginați-vă că scriem o metodă pentru a crea o lume populată de oameni. Numărul inițial de persoane este trecut ca argument. Deci trebuie să adăugăm excepții dacă sunt prea puțini oameni.

public void createWorld(int n) throws EmptyWorldException, LonelyWorldException
{
   if (n == 0)
      throw new EmptyWorldException("There are no people!");
   if (n == 1)
      throw new LonelyWorldException ("There aren't enough people!");
   System.out.println("A wonderful world was created. Population: " + n);
}

Acest apel de metodă poate fi gestionat în 3 moduri:

1. Nu prinde nicio excepție

Acest lucru se face cel mai adesea atunci când metoda nu știe cum să gestioneze corect situația.

public void createPopulatedWorld(int population)
throws EmptyWorldException, LonelyWorldException
{
   createWorld(population);
}

2. Prinde unele dintre excepții

Ne ocupăm de erorile pe care le putem gestiona. Dar pe cei pe care nu îi înțelegem, îi aruncăm până la metoda de chemare. Pentru a face acest lucru, trebuie să adăugăm numele lor la clauza throws:

public void createNonEmptyWorld(int population)
throws EmptyWorldException
{
   try
   {
      createWorld(population);
   }
   catch (LonelyWorldException e)
   {
      e.printStackTrace();
   }
}

3. Prinde toate excepțiile

Dacă metoda nu aruncă excepții de la metoda de apelare, atunci metoda de apelare este întotdeauna sigură că totul a funcționat bine. Și nu va putea lua nicio măsură pentru a remedia situații excepționale.

public void createAnyWorld(int population)
{
   try
   {
      createWorld(population);
   }
   catch (LonelyWorldException e)
   {
      e.printStackTrace();
   }
   catch (EmptyWorldException e)
   {
      e.printStackTrace();
   }
}

3. Prinderea mai multor excepții

Programatorii chiar urăsc să dubleze codul. Au venit chiar și cu un principiu de dezvoltare corespunzător - DRY : Don't Repeat Yourself. Dar când se gestionează excepții, există ocazii frecvente când un trybloc este urmat de mai multe catchblocuri cu același cod.

Sau ar putea fi 3 catchblocuri cu același cod și alte 2 catchblocuri cu alt cod identic. Aceasta este o situație standard când proiectul dumneavoastră gestionează excepțiile în mod responsabil.

Începând cu versiunea 7, în limbajul Java a adăugat posibilitatea de a specifica mai multe tipuri de excepții într-un singur catchbloc. Arata cam asa:

try
{
   // Code where an exception might occur
}
catch (ExceptionType1 | ExceptionType2 | ExceptionType3 name)
{
   // Exception handling code
}

Puteți avea câte catchblocuri doriți. Cu toate acestea, un singur catchbloc nu poate specifica excepții care se moștenesc reciproc. Cu alte cuvinte, nu puteți scrie catch ( Exception| RuntimeExceptione), deoarece RuntimeExceptionclasa moștenește Exception.