Exceptions und Assertions

Das Thema der Exceptions ist ein absolut essentielles, ohne das Java nicht auskäme. Es geht um die Behandlung von Ausnahmen, die während dem Ausführen von Programmen auftreten können. Werden diese vom Programmierer nicht richtig behandelt, kann dies zu Programmabstürzen u.Ä. führen.

Was ist eine Exception

Eine Exception ist eine Ausnahme, die immer dann auftreten kann, wenn Quelltext ausgeführt wird.
Die Bandbreite dieser Situationen ist fielfältig:
  • Möchtest Du eine Datei öffnen, die aber nicht gefunden werden kann, führt dies zu einer FileNotFoundException.
  • Möchtest Du auf ein Array zugreifen, verwendest aber als Index bspw. eine negative Zahl, bekommst Du eine IndexOutOfBoundsException.
  • Rufst Du auf einer null-Referenz eine Methode auf, führt das zu einer NullPointerException
  • ...
Exceptions zeigen also an, wenn etwas nicht so läuft, wie es eigentlich soll. Die Java-API macht regen Gebrauch von Exceptions (wie die obigen Beispiele zeigen), sie begegnen einem ständig im Programmierer-Alltag.
Natürlich kann man aber auch selbst Exceptions in seinen eigenen Code einbauen und sollte dies auch tun, um so auf mögliche Ausnahmen aufmerksam zu machen. Man kann sogar einen Schritt weitergehen und eigene Typen von Exceptions erstellen, bspw. eine KuehlschrankIstLeerException, o.Ä.

Zwei Arten von Ausnahmen: Checked und unchecked Exceptions

Java unterscheidet zwei Arten von Excpetions: Die s.g. checked und die unchecked Exceptions. Letztere werden auch RuntimeExceptions genannt.

Doch worin liegt der Unterschied? Werfen wir hierzu einen Blick auf die Klassenhierarchie:


(Quelle: https://www.seleniumeasy.com/java-tutorials/exception-handling-in-selenium-webdriver-using-java-examples)

Alle Subtypen der Klasse RuntimeException sind unchecked Exceptions.
Alle Subtypen der Klasse Exception, die wiederum kein Untertyp RuntimeException sind, sind checked Exceptions.

Warum die Unterscheidung?

Es gibt Ausnahmen, auf die reagiert werden muss. Der Programmierer muss sich also zwingend Gedanken darüber machen, was passieren soll, wenn diese Art von Ausnahme auftritt.
Dies ist bei allen checked Exceptions der Fall!

Die unchecked Exceptions zeichnen sich dadurch aus, dass sie zwar auftreten können, der Programmierer sich aber im Vorfeld keine Gedanken über deren Behandlung machen muss.

Dass es diese Unterscheidung in Java gibt, ist nicht unumstritten. In meinen Augen ist sie aber durchaus sinnvoll, zumal sie letztlich zu stabilierem Code führt.

Auf checked Exceptions reagieren

Schreibe ich Quelltext, verwende ich hierzu Klassen, die entweder aus der Java-API oder von mir selbst stammen. Durch Methodenaufrufe stoße ich die gewünsche Funktionalität an, die wiederum zu auftretenden Ausnahmen führen kann.
Mögliche auftretende checked Exceptions müssen bei der Deklaration der Methode mit angegeben werden:
 public class Foo {

  public static void hallo() throws IOException {

  }
 }
Dieser Code zeigt an, dass beim Aufruf der Methode hallo eine checked Exception (hier vom Typ IOException) auftreten, oder wie es im Java-Sprech heißt, geworfen werden kann.

Da es sich um eine checked Exception handelt, muss ich sie behandeln. Dies geht mittels des s.g. try-catch-Statement:
 public static void main(String[] args) {

  try {

   hallo();
 } catch (IOException e) {

   // Hier komme ich rein, wenn die Exception tatsächlich aufgetreten ist
  }
 }
Ich versuche (try) die Methode hallo auszuführen. Für den Fall, dass diese eine IOException wirft, fange (catch) ich diese. Der catch-Block wird als Konsequenz dessen ausgeführt. Hierin muss ich dann die Fehlerbehandlung machen.

Auf unchecked Exceptions reagieren

Unchecked Exceptions, also RuntimeExceptions, müssen nicht zwingend behandelt werden. Der Programmierer ist also nicht verpflichtet, ein try-catch-Statement zu verwenden:
 public static void hallo() throws RuntimeException {

 }

 public static void main(String[] args) {

  // ist ohne Fehlerbehandlung erlaubt!
  hallo();
 }
Obwohl die Methode hallo eine RuntimeException wirft, kann ich sie ohne ein try-catch-Statement aufrufen.

Was ist noch zu beachten

Obige Beispiele stellen, wenn man es so will, den Standardfall dar. Bei der Fehlerbehandlung, sei es von checked oder unchecked Exceptions, hat der Programmierer einige Möglichkeiten. Oft ist es gar nicht so leicht zu entscheiden, ob, wann, wie und wo man Fehler behandelt.
Eins ist aber sicher: Man sollte das Thema wirklich ernst nehmen, sollte man stabile Software entwickeln wollen, die sich eben nicht aufhängt.
Willst Du das Thema der Fehlerbehandlung noch besser verstehen?
Created with