Eigene Exception-Klassen in Java schreiben

Dieser Artikel beschreibt, wie Sie in Java eigene Exception-Klassen schreiben und anwenden können.

Manchmal kann es sinnvoll sein, eigene Exceptions zu entwickeln und zu werfen. So können Sie bspw. wesentlich gezieltere Fehlermeldungen für bestimmte Situationen angeben. Ihr Programm kann auch genauer auf bestimmte Fehlersituationen reagieren. Sie müssen nicht immer eine eigene Exception-Klasse schreiben, sondern nur dann, wenn Ihnen die Standard-Exceptions von Java nicht geeignet erscheinen.

Eigene Exception-Klassen

Sie müssen Ihre Exceptionklassen von der Klasse java.lang.Exception ableiten. Die Klassen sollten mindestens zwei Konstruktoren definieren:

der leere Standardkonstruktor und
einen Konstruktor der einen String mit einer Fehlermeldung erhält

Im folgenden Beispiel sehen Sie eine Artikel-Klasse mit einer Artikelnummer. Die Artikelnummer muss vierstellig sein. Ist dies nicht der Fall, wird eine Exception vom Typ IdInvalidException geworfen. Diese Ausnahme ist eine eigene Exception-Klasse.

Definieren der eigenen Exception

Im folgenden Quellcode sehen Sie die Klasse IdInvalidException. Ihre selbst erstellen Ausnahmen sollten der Konvention folgend immer mit dem Suffix Exception enden, damit sie eindeutig als Ausnahme markiert sind.

Verwenden der eigenen Exception

In der Klasse Artikel wird im Konstruktor geprüft, ob die Artikelnummer gültig ist. Ist dies nicht der Fall, wird eine Exception vom Typ IdUnvalidException geworfen. Sie wird nicht im Konstruktor behandelt, sondern an die aufrufende Methode weitergegeben, also an die Methode, welche den Konstruktor aufgerufen hat. Dort wird der Fehler entsprechend der Benutzeroberfläche behandelt, da es sich um einen Eingabefehler des Benutzers handelt. Hier sehen Sie wieder das mehrschichtige Verfahren.

Beim Auslösen der Exception wird dem Konstruktor eine Fehlermeldung mitgegeben, die als Konstante definiert ist. Die Artikelklasse interessiert sich nicht dafür, wie Ausnahme behandelt wird. Sie sagt nur, dass eine Ausnahme behandelt werden muss und übergibt die Verantwortung an die höhere Schicht.

Abfangen der Ausnahme

In der aufrufenden Methode, hier in der main-Methode, wird die Ausnahme abgefangen. Dies geschieht wie bei allen anderen Ausnahmen auch. Ausgegeben wird die Fehlermeldung, die in der Artikel-Klasse definiert wurde.

Komplexere Ausnahmen definieren

Wenn wir einmal bei unserer Artikelklasse bleiben, kann man sich viele weitere Ausnahmesituationen vorstellen:

Keine Artikelnummer eingegeben,
keine Bezeichnung eingegeben,
negativen Preis eingebeben,
ungültigen Lagerort eingegeben
usw.

Wir können nicht für jede Möglichkeit eine eigene Ausnahmeklasse definieren, die nur aus zwei Konstruktoren besteht und nur eine andere Fehlermeldung ausgibt. Eine Möglichkeit, um dieses Problem zu lösen, ist die folgende.

Wir deklarieren eine Klasse namens ArtikelException. Sie enthält alle Ausnahmefälle, die unsere Artikel-Klasse betreffen.In statischen Methoden nimmt sie Prüfungen vor und wirft im Fehlerfall sich selbst mit der entsprechenden Fehlermeldung.

public class ArtikelException extends Exception { public static final String WRONG_ARTIKEL_ID = "Die Artikelnummer muss zwischen 999 und 10000 liegen"; public static final String NEGATIVE_PRICE = "Der Preis darf nicht negativ sein."; public ArtikelException() { } public ArtikelException(String message) { super(message); } public static void checkArtikelNr(int artikelNr) throws ArtikelException { if (artikelNr = 10000) { throw new ArtikelException(WRONG_ARTIKEL_ID); } } public static void checkPrice(float price) throws ArtikelException { if (price

Diese statische Methode wird im Konstruktor von Artikel oder in allen anderen Methoden, welche die Artikelnummer prüfen müssen, aufgerufen. Im Fehlerfall wird die Exception geworfen mit der entsprechenden Fehlermeldung geworfen, die als Konstanten definiert sind.

In der main-Methode werden die Fehler behandelt. Oder in welcher Methode auch immer im späteren Programm die Artikel erzeugt und die Ausnahmen aufgefangen werden sollen. Sie sehen auch hier wieder eine mehrschichtige Architektur, bei der alles sehr geordnet ist. Die Fehlermeldungen werden an den richtigen Stellen geworfen, die Verantwortlichkeiten sind klar und wir haben letztendlich eine überschaubare Menge an Exception-Klassen. Außerdem werden Benutzereingabefehler wirklich in der Benutzeroberfläche behandelt - dort gehören sie hin, während sie von den Fachklassen (bei uns Artikel) geworfen werden.