Soorten uitzonderingen

1. Soorten uitzonderingen

Alle uitzonderingen zijn onderverdeeld in 4 typen, die eigenlijk klassen zijn die elkaar overerven.

Throwableklas

De basisklasse voor alle uitzonderingen is de Throwableklasse. De Throwableklasse bevat de code die de huidige call-stack (stacktracering van de huidige methode) naar een array schrijft. We zullen later leren wat een stacktracering is.

De throw- operator kan alleen een object accepteren dat is afgeleid van de Throwableklasse. En hoewel je in theorie code kunt schrijven als throw new Throwable();, doet meestal niemand dit. Het belangrijkste doel van de Throwableklasse is om één enkele bovenliggende klasse te hebben voor alle uitzonderingen.

Errorklas

De volgende uitzonderingsklasse is de Errorklasse, die de klasse rechtstreeks overerft Throwable. De Java-machine maakt objecten van de Errorklasse (en zijn afstammelingen) wanneer er ernstige problemen zijn opgetreden . Bijvoorbeeld een hardwarestoring, onvoldoende geheugen, enz.

Gewoonlijk kun je als programmeur niets doen in een situatie waarin een dergelijke fout (het soort waarvoor een Errormoet worden gegenereerd) in het programma is opgetreden: deze fouten zijn te ernstig. Het enige wat u kunt doen is de gebruiker op de hoogte stellen dat het programma crasht en/of alle bekende informatie over de fout naar het programmalogboek schrijven.

Exceptionklas

De klassen Exceptionen RuntimeExceptionzijn voor veelvoorkomende fouten die optreden bij de werking van veel methoden. Het doel van elke gegooide uitzondering is om te worden opgevangen door een catchblok dat weet hoe het op de juiste manier moet worden afgehandeld.

Wanneer een methode om de een of andere reden zijn werk niet kan voltooien, moet deze de aanroepende methode onmiddellijk op de hoogte stellen door een uitzondering van het juiste type te genereren.

Met andere woorden, als een variabele gelijk is aan null, zal de methode een NullPointerException. Als de onjuiste argumenten aan de methode zijn doorgegeven, wordt een InvalidArgumentException. Als de methode per ongeluk door nul deelt, wordt een ArithmeticException.

RuntimeExceptionklas

RuntimeExceptionszijn een subset van Exceptions. We zouden zelfs kunnen zeggen dat RuntimeExceptiondit een lichtgewicht versie is van gewone uitzonderingen ( Exception) — aan dergelijke uitzonderingen worden minder eisen en beperkingen gesteld

Je leert het verschil tussen Exceptionen RuntimeExceptionlater.

2. Throws: aangevinkte uitzonderingen

Alle Java-uitzonderingen vallen in 2 categorieën: aangevinkt en niet aangevinkt .

Alle uitzonderingen die de uitzonderingen erven RuntimeExceptionof Errorworden beschouwd als ongecontroleerde uitzonderingen . Alle andere zijn gecontroleerde uitzonderingen .

Wat is het belangrijkste verschil tussen aangevinkte en ongecontroleerde uitzonderingen?

Aan aangevinkte uitzonderingen worden aanvullende eisen gesteld . Grofweg zijn dit deze:

Vereiste 1

Als een methode een aangevinkte uitzondering genereert , moet deze het type uitzondering aangeven in de handtekening . Op die manier weet elke methode die het aanroept dat deze "betekenisvolle uitzondering" erin kan voorkomen.

Geef aangevinkte uitzonderingen aan na de methodeparameters achter het throwstrefwoord (gebruik het trefwoord niet throwper ongeluk). Het ziet er ongeveer zo uit:

type method (parameters) throws exception

Voorbeeld:

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!");
}

In het voorbeeld aan de rechterkant genereert onze code een ongecontroleerde uitzondering — er is geen aanvullende actie vereist. In het voorbeeld aan de linkerkant genereert de methode een aangevinkte uitzondering, dus het throwssleutelwoord wordt toegevoegd aan de handtekening van de methode, samen met het type uitzondering.

Als een methode meerdere aangevinkte uitzonderingen verwacht , moeten ze allemaal worden opgegeven na het throwstrefwoord, gescheiden door komma's. De volgorde is niet belangrijk. Voorbeeld:

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");
}

Vereiste 2

Als u een methode aanroept die uitzonderingen in zijn handtekening heeft gecontroleerd , kunt u niet negeren dat deze uitzonderingen genereert.

U moet al dergelijke uitzonderingen opvangen door catchvoor elke uitzondering blokken toe te voegen, of door ze toe te voegen aan een throwsclausule voor uw methode.

Het is alsof we zeggen: " Deze uitzonderingen zijn zo belangrijk dat we ze moeten opvangen. En als we niet weten hoe we ze moeten aanpakken, dan moet iedereen die onze methode aanroept, ervan op de hoogte worden gebracht dat dergelijke uitzonderingen erin kunnen voorkomen.

Voorbeeld:

Stel je voor dat we een methode schrijven om een ​​door mensen bevolkte wereld te creëren. Het aanvankelijke aantal mensen wordt als argument doorgegeven. We moeten dus uitzonderingen toevoegen als er te weinig mensen zijn.

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);
}

Deze methodeaanroep kan op 3 manieren worden afgehandeld:

1. Vang geen uitzonderingen op

Dit wordt meestal gedaan wanneer de methode niet weet hoe ze de situatie goed moet aanpakken.

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

2. Vang enkele van de uitzonderingen op

Wij pakken de fouten aan die we aankunnen. Maar degenen die we niet begrijpen, gooien we over naar de aanroepmethode. Om dit te doen, moeten we hun naam toevoegen aan de throws-clausule:

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

3. Vang alle uitzonderingen op

Als de methode geen uitzonderingen op de aanroepende methode genereert, is de aanroepende methode er altijd zeker van dat alles goed werkte. En het zal geen actie kunnen ondernemen om uitzonderlijke situaties op te lossen.

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

3. Meerdere uitzonderingen opvangen

Programmeurs hebben er echt een hekel aan om code te dupliceren. Ze kwamen zelfs met een bijbehorend ontwikkelprincipe: DRY : Don't Repeat Yourself. Maar bij het afhandelen van uitzonderingen komt het regelmatig voor dat een tryblok wordt gevolgd door meerdere catchblokken met dezelfde code.

Of er kunnen 3 catchblokken zijn met dezelfde code en nog eens 2 catchblokken met een andere identieke code. Dit is een standaardsituatie wanneer uw project verantwoord omgaat met uitzonderingen.

Vanaf versie 7 is in de Java-taal de mogelijkheid toegevoegd om meerdere soorten uitzonderingen in één catchblok op te geven. Het ziet er ongeveer zo uit:

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

Je kunt zoveel catchblokken hebben als je wilt. Een enkel blok kan echter catchgeen uitzonderingen specificeren die elkaar overerven. Met andere woorden, u kunt catch ( Exception| RuntimeExceptione) niet schrijven, omdat de RuntimeExceptionklasse overerft Exception.