Wat is het verschil tussen checked en unchecked exceptions in Java, hoe ontwerp je correcte foutafhandeling en welke fouten moeten worden vermeden bij hun gebruik?

Antwoord

In Java worden uitzonderingen onderverdeeld in checked (gecontroleerd) en unchecked (niet-gecontroleerd).

• Checked exceptions — zijn afgeleid van Exception, maar niet van RuntimeException. De compiler vereist expliciete afhandeling met try-catch of een declaratie in throws.
• Unchecked exceptions — zijn afgeleid van RuntimeException. De compiler vereist geen verplichte afhandeling.

public void readFile(String file) throws IOException { /* ... */ } // checked
public void divide(int a, int b) { int res = a/b; } // unchecked (ArithmeticException)

De belangrijkste nuance is dat checked exceptions worden gebruikt voor verwachte, herstelbare situaties (bijvoorbeeld invoer- en uitvoerfouten), terwijl unchecked exceptions worden gebruikt voor fouten in de logica van de code of kritieke situaties waaruit niet kan worden hersteld (bijvoorbeeld NullPointerException).

Misleidende vraag

Vraag: Moet je een unchecked exception afhandelen of declareren in throws als jouw methode deze kan gooien?

Antwoord: Nee. De compiler vereist geen controle of declaratie van niet-herstelbare (unchecked) uitzonderingen. Het afhandelen is aan u; je kunt try-catch gebruiken, maar vaak is het beter om ze "te laten vallen" tot aan de globale handler.

public void foo() { throw new IllegalArgumentException(); } // Vereist geen afhandeling of declaratie

Voorbeelden van echte fouten door gebrek aan kennis over de nuances van het onderwerp

---

Verhaal

In een project van de bancaire API werden er RuntimeException gegooid bij het afhandelen van invoer- en uitvoerfouten in plaats van checked exceptions. Dit resulteerde erin dat klanten niet gedwongen werden om deze te behandelen, wat leidde tot onjuiste werking bij het verliezen van de verbinding met de server, en de applicatie "viel" zonder de gebruiker te informeren.

---

Verhaal

Een ontwikkelaar verklaarde een overmatige hoeveelheid throws Exception in de handtekeningen van de methoden (bijvoorbeeld databases), waardoor alle gebruikte methoden bovenaan gedwongen werden om either try-catch of ook throws te gebruiken. Dit vervuilde de code, verminderde de leesbaarheid en bemoeilijkte de refactoring.

---

Verhaal

In een van de microservices werden alle uitzonderingen gevangen in een algemene catch (Exception e). Dit vatte ook unchecked exceptions (bijvoorbeeld NullPointerException) op, wat leidde tot "stille" negering van kritieke fouten — de service werkte met onjuiste gegevens.