Grundlagen der Informatik I “Programmierung”

Diese Vorgehensweise würde jedoch zu einer Unmenge überflüssigen Programmtextes führen, da in den meisten
Fällen die Vorbedingungen der aufgerufenen Routine durch die vorhergehenden Anweisungen sichergestellt
wurden. Meist ist dies offensichtlich (z.B. wenn kurz vor dem Aufruf von item(i) die Zuweisung i:=lower
steht). In den Fällen, wo dieser Zusammenhang nicht so offensichtlich ist, sollte man eine Aussage über diese
Eigenschaft in den Programmtext mit aufnehmen, die klarstellt, daß man sich bei der Implementierung über die
Situation durchaus im klaren war und daß jede Änderung des Programmtextes auf diese Programmeigenschaft
Rücksicht zu nehmen hat.
Eiffel bietet die Möglichkeit an, auch diese Aussagen als überprüfbare Zusicherungen innerhalb einer check-
Anweisung zu formulieren. Eine solche Anweisung beginnt mit dem Schlüsselwort check und enthält dann
eine Reihe von Zusicherungen, die mit end abgeschlossen werden.
check
Zusicherung1;
Zusicherung2;
.
Zusicherungn
end
Als Zusicherungen sind die Ausdrücke der Zusicherungssprache von Eiffel (Sektion 3.7) erlaubt. Sie werden
bei Ausführung der check-Anweisung überprüft, sofern die entsprechenden Parameter im System Definition
File gesetzt sind. In diesem Falle bricht das Programm ab, falls eine der Zusicherungen verletzt ist. Da die
Ausdruckskraft der Zusicherungen jedoch begrenzt ist und die Überprüfung von Zusicherungen Laufzeit kostet,
geht die Rolle der Check-Anweisungen nur selten über die eines sinnvoll plazierten Kommentars hinaus.
Man sollte sich daher darüber im klaren sein, daß eine Überprüfung von Zusicherungen kein Ersatz für einen
Korrektheitsbeweis sein kann, sondern bestenfalls – in Verbindung mit dem Ausnahmemechanismus, den wir
im folgenden Abschnitt besprechen – eine zusätzliche Absicherung gegenüber unkontrollierbarem Verhalten
des Gesamtsystems, falls darin – was leider sehr wahrscheinlich ist – auch unverifizierte Klassen zum Einsatz
kommen, die eventuell gewisse Abmachungen wie die Vorbedingungen eines Routinenaufrufs nicht einhalten. 30
4.3.7 Umgang mit Fehlern: Disziplinierte Ausnahmen
In einer idealen Programmierwelt wären alle Programme als korrekt nachgewiesen und gegenüber jeglicher
Form von Fehlbedienung abgesichert. Leider aber sind wir von beiden Zielen noch weit entfernt. Zum einen
gibt es zu wenig Werkzeuge, welche eine Verifikation von Programmen unterstützen, und zum anderen ist es
ausgesprochen aufwendig, Programme robust zu gestalten.
Wird zum Beispiel vom Benutzer eines Programms eine numerische Eingabe erwartet, so muß man damit
rechnen, daß sich der Benutzer bei der Eingabe vertippt und innerhalb der eingegebenen Ziffernfolge ein
Buchstabe auftritt. Die verwendete Eingaberoutine (readreal, siehe Abschnitt 4.3.9) kann daher ihren Kontrakt
nicht erfüllen und keine Zahl an die aufrufende Stelle zurückgeben. Sie bricht also ihre Tätigkeit in einer
Art “organisierter Panik” ab und hinterläßt ein Fehlersignal (das feature error hat einen Wert ungleich Null).
Sicherlich wäre es nicht sinnvoll, beim Auftreten eines solchen Fehlers gleich das gesamte Programm abzubrechen.
Bei einer erneuten Aufforderung würde der Benutzer seine Eingabe sicherlich mit größerer Konzentration
wiederholen. Man könnte also jede Eingaberoutine in eine Schleife einbetten, die solange wiederholt wird, bis
kein Fehlersignal mehr auftritt. Diese Vorgehensweise hätte jedoch den Nachteil, daß das Programm unnötig
durch Schleifen aufgebläht wird und der Ausnahmefall das eigentliche Programm dominiert.
Ebenso muß man damit rechnen, daß bei der Überprüfung von Zusicherungen festgestellt wird, daß eine
der vorgesehenen Bedingungen – zum Beispiel die Vorbedingung einer Routine – nicht eingehalten wird. Die
aufgerufene Routine kann diesen Fehler nicht beheben. Es wäre aber auch nicht sinnvoll, über einen einmal
30 Eine ausführliche Diskussion über einen sinnvollen Einsatz des Überprüfungsmechanismus bei möglichst geringen Laufzeit-
verlusten findet man in [Meyer, 1988, Kapitel 7.10.1/2]