Ausnahmebehandlung

Eine Ausnahme oder Ausnahmesituation (englisch exception) bezeichnet in der Computertechnik ein Verfahren, Informationen über bestimmte Programmzustände – meistens Fehlerzustände – an andere Programmebenen zur Weiterbehandlung weiterzureichen.

Kann in einem Programm beispielsweise einer Speicheranforderung nicht stattgegeben werden, wird eine Speicheranforderungs-Ausnahme ausgelöst. Ein Computerprogramm kann zur Behandlung dieses Problems dafür definierte Algorithmen abarbeiten, die den Fehler beheben oder anzeigen.

Strukturierte Ausnahmebehandlung

Die größte Rolle in der Programmierung spielt dabei die strukturierte Ausnahmebehandlung (englisch structured exception handling, kurz SEH), eine Technik, die den Code zur Ausnahmebehandlung vom normalen Anwendungscode getrennt hält. Anstatt beispielsweise bei jedem Funktionsaufruf einen Rückgabewert, der den Erfolg anzeigt, zu prüfen und darauf zu reagieren, kann man die betreffende Funktion in Ausnahmesituationen eine Ausnahme auslösen lassen, die alle für die Problemerkennung und -behandlung erforderlichen Informationen in sich trägt.

Da die verursachende Funktion (oder die Funktion, die das Problem feststellt) in ihrem Kontext den Fehler möglicherweise nicht angemessen behandeln kann, wird die Exception so lange an aufrufende Funktionen zurückgereicht, bis schließlich eine die Exception „fängt“. Dies baut man sinnvollerweise an einer Stelle im Code ein, wo abzusehen ist, was für Konsequenzen diese Ausnahme haben kann und wie man darauf am besten reagiert (zum Beispiel neue Benutzereingabe, Programmabbruch, Abbruch einer bestimmten Operation). Außerdem ist jeder Code-Abschnitt, der bezüglich der Ausnahmebehandlung nichts ausrichten kann, frei von Fehlerbehandlungsroutinen.

Ein weiterer entscheidender Vorteil gegenüber der Fehlerbehandlung über Rückgabewerte ist, dass eine Exception nicht ignoriert werden kann. Ein Programmierer könnte vergessen, einen Rückgabewert zu prüfen, aber eine Exception wird immer weiter zurückgereicht - im Extremfall so lange, bis sie in der programmstartenden Funktion ankommt, falls der Programmierer es unterlassen hat, sie abzufangen. In diesem Fall führt das oft zu einem Programmabbruch. Dies mag etwas subtil erscheinen, das Resultat ist jedoch meistens, dass Programme, die trotz Fehlerbehandlung per Exceptions stabil laufen, auch wirklich stabil laufen. Demgegenüber kann das Ignorieren eines Fehlerwertes viele Male keine drastischen Konsequenzen haben und irgendwann könnte das Programm eventuell doch unerwartete Ergebnisse produzieren.

Programmiersprachen, die Ausnahmebehandlung unterstützen, sind zum Beispiel C++, Java, C#, Object Pascal, Visual Basic .NET, PHP (ab Version 5), Python, Common Lisp, Ruby, Eiffel, Ada und Objective CAML.

Verschiedene Hardware-Architekturen (wie zum Beispiel die IA-32-Architektur von Intel) unterstützen eine Exception-Behandlung auf Hardware-Ebene durch das Betriebssystem. Hierbei werden bei bestimmten ungültigen Operationen Software-Interrupts ausgelöst, die einen Einsprung in den privilegierten Betriebssystemkern verursachen. Dieser kann dann anhand der Exception das Programm mit einer Fehlermeldung beenden oder den Fehler an einen Debugger weiterleiten.

Checked Exceptions

Bei Java gibt es als Weiterentwicklung der Ausnahme die „Checked Exception“ (dt. etwa: überprüfte Ausnahme). Das ist eine Ausnahme, bei der der Compiler prüft, ob alle Stellen, wo sie auftreten kann, durch Code zum Abfangen der Ausnahme abgedeckt sind. Der Code zum Abfangen kann dabei innerhalb derselben Methode stehen, in der die Ausnahme auftreten kann, oder auch in aufrufenden Methoden. In letzterem Fall muss der Programmierer die Ausnahmen in der Methodensignatur deklarieren.

Die zugrunde liegende Idee beim Entwurf von Java war, dass Ausnahmen, auf die der Anwendungscode sinnvoll reagieren kann, als Checked Exception ausgeführt werden. Durch den Zwang zur Behandlung der Ausnahme sollte robuster Code erreicht werden und fehlende Fehlerbehandlungen bereits vom Compiler entdeckt werden.<ref>Ann Wohlrath: Re: Toward a more “automatic” RMI = compatible with basic RMI phi loso phy, archives.java.sun.com, abgerufen 9. Oktober 2008</ref> Es gibt aber weiterhin Ausnahmen, die keine Checked Exceptions sind. Als Konvention gilt dabei, solche Fehler als Checked Exception zu realisieren, bei denen man vom Aufrufer erwartet, dass er auf ihn reagieren und einen geregelten Programmablauf wiederherstellen kann. Darunter fallen beispielsweise Netzwerk-, Datenbank- oder sonstige E/A-Fehler. So kann das Öffnen einer Datei aus verschiedenen Gründen fehlschlagen (keine Rechte, Datei nicht vorhanden), der Aufbau einer Netzwerkverbindung kann aus vom Programm nicht zu beeinflussenden Gründen fehlschlagen. Nicht-Checked-Exceptions sind zum Melden verschiedener Arten von Programmfehlern vorgesehen (zum Beispiel Indexfehler bei Array-Indizierung). Es wird davon abgeraten, die Anwendung in solchen Fällen versuchen zu lassen, einen geregelten Programmablauf wiederherzustellen.<ref>Joshua Bloch: Effective Java. Addison-Wesley, 2001, ISBN 0-201-31005-8, S. 172 ff.</ref> Die Klassen der Java-Plattform selber halten sich weitgehend an diese Konvention.

Kritiker führen gegen die Checked Exceptions an, dass sie die Lesbarkeit des Quellcodes verschlechtern würden und dass sie viele Programmierer, weil sie in dieser Funktionalität keinen dem Aufwand entsprechenden Nutzen erkennen, zu Ausweichkonstrukten verleiten, die dem Compiler genügen, aber kaum Fehler behandeln.<ref>Bruce Eckel: Does Java need Checked Exceptions? abgerufen 9. Oktober 2008</ref> Ein anderer Einwand ist, dass aufgrund der Deklaration der Exceptions in den Methodensignaturen allgemein verwendbare Hilfsklassen oder Interfaces, insbesondere als Teil von Entwurfsmustern, oft nicht sinnvoll operabel sind mit Klassen, die Checked Exceptions verwenden.<ref>Java’s checked exceptions were a mistake. Rod Waldhoff’s Weblog, abgerufen 9. Oktober 2008</ref> Als Ausweichlösung werden getunnelte Checked Exceptions vorgeschlagen, die aber den Nutzen der Checked Exception aufheben.<ref>ExceptionTunneling c2</ref>

Auslösen von Exceptions

Eine Exception kann an jeder Stelle im Programmcode ausgelöst werden. Dabei wird fast immer ein Objekt einer Exception-Klasse erzeugt und mit dem Schlüsselwort throw oder raise abgeschickt. Bei manchen Programmiersprachen (zum Beispiel C++) darf statt der Exception-Klasse auch jeder andere Datentyp verwendet werden.

Abfangen von Exceptions

Wird eine Exception im Programmablauf nicht explizit abgefangen, dann wird sie von der Laufzeitbibliothek aufgefangen. Die Exception wird als Fehlermeldung angezeigt; je nach Art der Exception wird die Anwendung abgebrochen oder fortgesetzt. Anwendungen ohne eigene Benutzeroberfläche werden immer abgebrochen.

Häufige Fehler bei der Ausnahmebehandlung sind:

• Exceptions werden ohne weitere Aktionen geschluckt. Somit geht die eigentliche Fehlerursache verloren.
• Exceptions werden durch eine eigene (häufig unzutreffende) Meldung ersetzt.

Es ist sinnvoll, Exceptions abzufangen, um zusätzliche Informationen anzureichern und erneut auszulösen.

Beispiele

Object Pascal

<syntaxhighlight lang="delphi"> ObjektA := TObjectA.Create; try

 try
   BerechneEinkommen(Name);
 except
   on E:Exception do
   begin
     // Exception wurde abgefangen und wird um einen aussagekräftigen Hinweis ergänzt
     E.Message := 'Fehler beim Berechnen des Einkommens von ' + Name + #13#10 +
       E.Message; // ursprüngliche Meldung anhängen
     raise;  // veränderte Exception erneut auslösen
   end;
 end;

finally

 FreeAndNil(ObjektA); // dies wird auf jeden Fall ausgeführt

end; </syntaxhighlight>

C++

<syntaxhighlight lang="cpp"> try {

   funktion1();
   funktion2();
  ...

} catch (const invalid_argument &e) {

   cerr << "Falsches Argument: "  << e.what() << endl;

} catch (const range_error &e) {

   cerr << "Ungültiger Bereich: " << e.what() << endl;

} catch (...) {

   cerr << "Sonstige Exception" << endl;

} </syntaxhighlight>

C#

<syntaxhighlight lang="csharp">

MessageServiceClient client = new MessageServiceClient("httpEndpoint"); Message message = ... // Message erstellen try {

  client.AddMessage(message);

} catch (FaultException fe) {

  Console.WriteLine(fe);
  client.Abort();

} catch (CommunicationException ce) {

  Console.WriteLine(ce);
  client.Abort();

} catch (TimeoutException te) {

  Console.WriteLine(te);
  client.Abort();

} </syntaxhighlight>

ISO Modula-2

<syntaxhighlight lang="modula2"> MODULE BeispielAusnahmebehandlung;

 (* Es gibt vordefinierte und benutzerdefinierte Ausnahmen *)

FROM M2EXCEPTION IMPORT M2Exception, IsM2Exception, M2Exceptions;

 (* Deklarationen etc. *)
 IF SpeicherFehler THEN
   RAISE BenutzerdefinierteAusnahme;
 END;

BEGIN

 (* Hauptprogramm *)

EXCEPT

 (* Ausnahmebehandlung *)

FINALLY

 (* Finalisierung *)

EXCEPT

 (* Sollte bei der Finalisierung etwas schiefgehen *)

END BeispielAusnahmebehandlung. </syntaxhighlight>

Visual Basic .NET

<syntaxhighlight lang="vb"> ' Versuche ... Try

 ' ... die Methode oder Prozedur ...
 BerechneEinkommen(name)

' bei Ausnahme Catch ex AS Exception

 ' gib Ausnahme aus
 MessageBox.Show("Fehler -> " & ex.message)

' Führe auf jeden Fall aus Finally

 MessageBox.Show("Das wird trotzdem ausgeführt")

End Try </syntaxhighlight>

Java

<syntaxhighlight lang="java"> try {

   // Berechne ...

} catch (OutOfMemoryError e) {

   // Ein Error ist keine Exception und muss separat abgefangen werden
   e.printStackTrace();

} catch (RuntimeException e) {

   // z. B. IndexOutOfBoundsException, NullPointerException usw.
   System.err.println("Offensichtlich ein Programmierfehler!");
   throw e; // Leite nach oben weiter

} catch (Exception e) {

   // Fange alle restlichen Ausnahmefehler ab
   e.printStackTrace();

} catch (Throwable t) {

   // Das hier fängt wirklich alles ab
   t.printStackTrace();

} finally {

   // Ob Exception oder nicht, führe das hier auf jeden Fall aus
   System.out.println("Berechnung beendet oder abgebrochen");

} </syntaxhighlight>

JavaScript

<syntaxhighlight lang="javascript"> try {

   // Berechne ...
   rechnen();
   // Fehler generieren
   throw new Error("Fehler, Datei kann nicht gelesen werden");

} catch (e) {

   // Fehlertypen unterscheiden (Achtung: dies hier ist nur eine kleine Auswahl)
   if (e instanceof ReferenceError) {
       console.log(e.message);

   } else if(e instanceof SyntaxError) {
     console.log(e.message);

   } else {
     console.log(e);
   }

} finally {

   // Wird immer ausgeführt, nachdem der Codeblock in "try" abgearbeitete ist
   weiter();

} </syntaxhighlight>

PHP

<syntaxhighlight lang="php"> // Exceptionhandling ab PHP Version 5! try {

   // Berechne ...

   // Fehlermeldung, Fehlercode
   throw new RuntimeException('Fehlermeldung', 543);

} catch (RuntimeException $e) {

   // z. B. IndexOutOfBoundsException, NullPointerException usw.
   // Wichtig: Um die hier verwendeten Basistypen zu nutzen,
   // muss die "SPL" installiert sein

   echo $e->getMessage();

   throw $e; // Leite nach oben weiter

} catch (Exception $e) {

   // Fange alle restlichen Ausnahmefehler ab und
   // verwende die __toString() - Methode zur Ausgabe

   echo $e;

} finally {

   // ab PHP 5.5
   // Code, welcher immer ausgeführt wird, auch
   // wenn ein Ausnahmefehler aufgetreten ist

} </syntaxhighlight>

Python

<syntaxhighlight lang="python"> try:

   result = doSomething()
   if result < 0:
       raise StandardError

except StandardError:

   print("catching exception")
   doSomethingElse()

except:

   print("exception in method doSomething")

</syntaxhighlight>

Siehe auch Python, Abschnitt Ausnahmebehandlung.

Perl

<syntaxhighlight lang="perl"> eval {

   something_fatalse(...);
   1;

} or do {

   warn "Exception: $@";

};

1. alternativ/ergänzend kann man auch objektorientierte Exception-Module verwenden

</syntaxhighlight>

Weblinks

• Brian Goetz: Exceptional practices. JavaWorld, Artikelserie
• Kyle Loudon: Programming with Exceptions in C++. O’Reilly Network
• Understanding and Using Exceptions in .NET Hinter den Kulissen des Win32-SEH (Structured Exception Handling)
• Errors and Exceptions. The Python Tutorial (englisch)

Einzelnachweise

<references />