Advanced   Java   Services

Exceptions and Errors

Es läuft nicht immer alles so, wie es gedacht war. Diese banale Weisheit stimmt auch für das Programmieren. Es passieren die unterschiedlichsten Fehler, für die einen ist man selbst verantwortlich, für andere wiederum nicht, die einen sind relativ harmlos, andere jedoch ziemlich katastrophal. Da man im Amerikanischen in diesem Zusammenhang "to throw an Error or an Exception" sagt, hat sich mittlerweile auch im Deutschen die Sprechweise "einen Fehler oder eine Ausnahme werfen" eingebürgert. Java hat für Fehler eigene Fehlerklassen eingeführt und unterscheidet zwei Arten von Fehler. Ein schlimmer Fehler heißt Error, ein weniger schlimmer Fehler heißt Exception bzw. Ausnahme. Dementsprechend gibt es eine Klasse Error und eine Klasse Exception. Alle Fehler sind Unterklassen von Error, alle Ausnahmen sind Unterklassen von Exception. Error und Exception haben eine gemeinsame Oberklasse mit dem schönen Namen Throwable ("Werfbares").

Es gibt nur zwei Möglichkeiten, entweder reagiert der Compiler oder der Interpreter zur Laufzeit des Programms. Wenn der Compiler reagiert, dann bricht er das Compilieren ab und fordert eine Fehlerbehandlung, kommt die Reaktion erst zur Laufzeit, dann bricht das Programm ab und der Interpreter bringt eine Fehlermeldung. es ist wichtig, diese zwei Situationen zu unterscheiden. dafür haben sich die folgenden Begriffe eingebürgert.

• checked exception
  Bei diesen Exceptions fordert bereits der Compiler ein Fehlerbehandlung
  
  
• unchecked exception
  Bei diesen Exceptions reagiert der Compiler nicht, sondern erst das Laufzeitsystem

Als Faustregel kann man sich schon mal merken, daß Error und alle von Error abgeleitete Klassen unchecked exceptions sind. Bevor wir genau klären, bei welchen Ausnahmen der Compiler einschreitet erst einmal einige Beispiele.

int[] arr = { 1, 2, 3 } ;
int i;

for(i=0; i<arr.length; i++)
   arr[i]++;

System.out.println(arr[i]) ;

Ein beliebter Fehler. Nach der Schleife hat i den Wert arr.length, aber der Feldindex arr.length existiert nicht. In C/C++ wird man auf diesen Fehler nicht aufmerksam gemacht. In Java läßt sich das Compilieren, aber der Aufruf endet dann mit der Meldung ArrayIndexOutOfBoundsException. Es handelt sich also um eine unchecked exception. Ein Blick in die API zeigt uns, daß ArrayIndexOutOfBoundsException eine Unterklasse von RuntimeException ist.

Thread.sleep(2000);

Mit der statischen Methode sleep() aus der Klasse Thread wollen wir den Programmablauf für 2 Sekunden unterbrechen. Hier verweigert bereits der Compiler seinen Dienst und bringt die Meldung

unreported exception java.lang.InterruptedException
must be caught or declared to be thrown

Offensichtlich handelt es sich hier um eine checked exception.

int zugross[] = new int[Integer.MAX_VALUE];

Hier reagiert wohl bei den meisten PC's das Laufzeitsystem mit der Meldung OutOfMemoryError und verabschiedet sich dann. Obwohl es sich hier um eine Unterklasse von Error handelt spricht man doch eher von unchecked exception und nicht von unchecked error.

int erg = Integer.parseInt("hallo");

Obwohl das nicht gut gehen kann prüft der Compiler hier nicht, also eine unchecked exception. Zur Laufzeit allerdings wird eine NumberFormatException geworfen.

FileReader fr;
String fileName="irgendeine.txt";
fr = new FileReader(fileName);
// unreported exception java.io.FileNotFoundException
// must be caught or declared to be thrown

Der Versuch, eine Datei zu öffnen schlägt fehl. Die Fehlermeldung des Compilers steht im Kommentar, also ein checked exception

Die nächste Graphik bringt einen Auszug aus den über 100 Exceptionklassen und zeigt, welche Exceptions vom Compiler gecheckt werden und welche nicht.

• checked exceptions
  
  alle Unterklassen von Exception mit Ausnahme von RuntimeException (nomen est...) und deren Unterklassen, sowie alle selbstentworfenen Unterklassen von Throwable und Exception.
  
  
• unchecked exceptions
  
  Throwable, Exception und Error, sowie alle Unterklassen von Error, auch die selbst entworfenen, zudem noch RuntimeException und alle Unterklassen von RuntimeException, auch die selbst entworfenen.

Die Graphik erweckt den Eindruck, als gäbe es mehr unchecked exceptions als checked exceptions. Das täuscht, allein Exception hat, RuntimeException ausgenommen, 54 direkte Unterklassen, Error dagegen hat nur 9 direkte Unterklassen mit relativ wenigen Nachkommen. RuntimeException hat 29 Nachkommen.