Soorten Exceptions

Exceptions versus errors

Het throw-statement kan een fout genereren door een object van de klasse Throwable te ‘werpen’. De klassen hiërarchie ziet er als volgt uit:

Van de klasse Throwable zijn er twee subklassen: Error en Exception. Beide klassen hebben uiteraard een aantal subklassen die niet op de afbeelding voorkomen.

Tot nog toe hebben we enkel gesproken over exceptions. Exceptions zijn uitzonderingstoestanden die de normale loop van het programma verstoren. Deze uitzonderingen kunnen opgevangen worden, zodat de nodige acties ondernomen kunnen worden.

Errors daarentegen zijn fundamentele fouten die optreden in de JVM en mogen normaal gezien niet voorkomen. Het heeft ook geen zin dit soort fouten af te handelen. Het is ook niet aangewezen om in een programma een error te genereren. Dergelijke fout kan bijvoorbeeld optreden als er onvoldoende geheugen beschikbaar is. De virtuele machine moet er dan noodgedwongen mee ophouden.

Checked exceptions versus runtime exceptions

In de klassen hiërarchie zien we dat de klasse Exception een subklasse RuntimeException heeft. Alle andere subklassen van Exception kan men plaatsen onder de noemer Checked exceptions. De subklassen van RuntimeException zijn dat niet.

Checked exceptions:

Checked exceptions zijn exceptions waarvoor de compiler controleert (checks) of ze in de loop van het programma worden opgevangen. Indien in een methode een exception gegenereerd wordt, kan men twee dingen doen:

1. Ofwel wordt de exception binnen de methode zelf nog opgevangen. Dit betekent dat er naar buiten toe geen exception gegenereerd wordt. (zoals voorgaande voorbeeld Rectangle)
2. Ofwel wordt er in de definitie van de methode gespecificeerd dat deze methode mogelijk een exception naar buiten toe kan genereren. Het genereren van een exception maakt bijgevolg deel uit van de interface van de methode. Op die manier wordt de gebruiker van de methode op de hoogte gebracht van eventuele exceptions die kunnen optreden.

De compiler controleert en geeft errors indien de methoden de exception opgevangen word en niet gespecificeerd is bij de methode definitie.

Runtime exceptions:

Runtime exceptions worden niet door de compiler gecontroleerd. Men is dus niet verplicht deze exceptions op te vangen of ze te specificeren in de definitie van de methoden

Runtime exceptions kunnen op zoveel plaatsen in het programma optreden dat het bijna niet doenbaar is om voor zulke exceptions de nodige opvang te implementeren. In ons voorbeeld van de deling ging het telkens om runtime exceptions. De exceptions NumberFormatException en ArithmeticException zijn namelijk afgeleid van de klasse RuntimeException.

Meestal wijzen runtime exceptions op programmeerfouten. Runtime exceptions zouden daarom alleen nog mogen optreden in de testfase van de software of bij heel uitzonderlijke toestanden. In de definitieve release zouden dit soort fouten bijna niet meer mogen voorkomen.