Java verwerkt fouten met try/catch/finally en onderscheidt uniek checked exceptions (moeten worden aangegeven of verwerkt) van unchecked exceptions (runtime, niet afgedwongen). Dit onderscheid is centraal voor Java-foutafhandeling.
Java verwerkt fouten met try/catch/finally en onderscheidt uniek checked exceptions (moeten worden aangegeven of verwerkt) van unchecked exceptions (runtime, niet afgedwongen). Dit onderscheid is centraal voor Java-foutafhandeling.
try {
FileReader f = new FileReader("file.txt"); // may throw IOException
// ... use it ...
} catch (FileNotFoundException e) {
System.out.println("not found: " + e.getMessage()); // specific first
} catch (IOException e) {
System.out.println("io error"); // broader after
} finally {
System.out.println("always runs — cleanup"); // runs no matter what
}
finally wordt altijd uitgevoerd (opruiming), zelfs als een exception wordt gegenereerd of een return optreedt.
Throwable
├── Error — serious JVM problems (OutOfMemoryError) — don't catch
└── Exception
├── RuntimeException → UNCHECKED (not enforced by the compiler)
│ NullPointerException, IllegalArgumentException, IndexOutOfBounds...
└── (other Exceptions) → CHECKED (compiler enforces handling)
IOException, SQLException...
// MUST either catch it or declare `throws` — the compiler won't let you ignore it
public void readFile() throws IOException { // declare it
Files.readAllLines(Paths.get("file.txt")); // throws checked IOException
}
Checked exceptions (IOException, SQLException) vertegenwoordigen herstelbare, verwachte omstandigheden (een ontbrekend bestand, een netwerkfout). De compiler dwingt u af om ze af te handelen of aan te geven — wat foutafhandeling voor externe fouten expliciet maakt.
// NOT required to declare or catch — usually indicate PROGRAMMING BUGS
String s = null;
s.length(); // NullPointerException (unchecked)
int x = arr[10]; // ArrayIndexOutOfBoundsException (unchecked)
Integer.parseInt("abc"); // NumberFormatException (unchecked)
Unchecked (RuntimeException-subklassen) duiden meestal op programmeerfouten — u lost de bug op in plaats van deze overal op te vangen. De compiler dwingt afhandeling niet af.
// resources implementing AutoCloseable are closed automatically
try (FileReader f = new FileReader("file.txt")) {
// use f
} // f.close() called automatically, even on exception — no finally needed
✓ Catch specific exceptions, not bare Exception
✓ Use try-with-resources for files/connections (auto-close)
✓ Don't swallow exceptions silently (empty catch blocks)
✓ Throw meaningful exceptions; include context in messages
✓ Custom exceptions extend Exception (checked) or RuntimeException (unchecked)
Robuste foutafhandeling is essentieel, en Javas checked/unchecked onderscheid is een kenmerkend (en betwist) kenmerk dat diep begrijpen waard is.
Checked exceptions dwingen expliciete afhandeling van verwachte externe fouten (I/O, DB) af — bevorderend betrouwbaarheid maar soms bekritiseerd als uitgebreid; unchecked exceptions vertegenwoordigen bugs die moeten worden opgelost in plaats van routine op te vangen.
De hiërarchie kennen, wanneer elk type van toepassing is, de try/catch/finally semantiek en modern try-with-resources voor automatische opruiming is fundamenteel voor het schrijven van correcte, betrouwbare Java — en voor het passend ontwerpen van uw eigen exceptions.
Het onderscheid bepaalt hoe Java-API's worden ontworpen en is een veelvoorkomend onderwerp in interviews en code reviews.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren