# Lava unterstützt Attached Assertions (ähnlich dem "Design By Contract DBC in SpracheEiffel): In der Methoden-Deklaration? kann man Vor- und Nachbedingungen des Methodenaufrufs deklarieren, die bei Verletzung entsprechende Exceptions auslösen. Lava-Klassen? (Interface und Implementation) können mit Invarianten versehen werden, die nach jedem Methodenaufruf gültig bleiben müssen, sonst Exception.

Zu Exceptions siehe auch http://lavape.sourceforge.net/doc/html/ExceptionSamples.htm

Zu Exceptions in SpracheLava siehe auch http://lavape.sourceforge.net/doc/html/ExceptionSamples.htm Exception-Handling? durch Callbacks: Das "typverzweigende" Exception-Handling? durch typspezifische "catch"-Klauseln ist ja eigentlich unbefriedigend und unerwünscht, weil es das objektorientierte Denken untergräbt. Das objektorientierte Exception-Handling? durch eine überschriebene "Object::catch"-Methode (s.o.) ist nur dann sinnvoll anwendbar, wenn derjenige, der die Exception behandelt, zugleich die abgeleitete Exceptionklasse "in der Hand hat", also nach seinen Vorstellungenn gestalten kann, insbesondere die überschriebene "catch"-Methode selbst programmieren kann, was meistens nicht der Fall sein wird, da die Exceptionklasse normalerweise von dem Programmierer der gerufenen Methode gestaltet werden wird. Ein angemessener objektorientierter Umgang mit diesen Fällen kann in Lava dadurch erreicht werden, dass die exception-auslösende Methode unmittelbar vor dem "Werfen" der Exception ein spezifisches "Signal" im Sinne des Lava-Callback-Konzeptes emittiert, für das der Methoden-Aufrufer? eine von ihm programmierte Callback-Methode? abonniert hat, die dann also vor dem formellen Auslösen der Exception auf Grund des emittierten Signals automatisch aufgerufen wird und die eigentliche Exceptionbehandlung übernimmt.

Siehe auch ExceptionsDiskussion, ExceptionsAlsArchitekturBestandteil, EinGutesExceptionBeispiel, ExceptionsConsideredHarmful, CheckedExceptionsConsideredHarmful.

Aus Sicht von SpracheLava ist ein Exception-Handling-Konzept? nicht nur sinnvoll, sondern geradezu unentbehrlich, da wir in SpracheLava generell anstreben, das versehentliche Arbeiten mit undefinierten Variablen-Werten? durch statische oder Laufzeit-Checks? zu verhindern, denn die Aufklärung solcher Fehler ist oft außerordentlich mühsam und zeitraubend:

Es kommt häufig vor, dass eine Methode einer Klasse nicht die normalerweise erwarteten Ergebnisse (Output-Parameter?, Return-Value?) liefern kann. Wenn in diesem Fall das Laufzeit-System? nicht verhindert, dass der Aufrufer diese Rückgabewerte (soweit sie von der Methode überhaupt schon vor dem Zeitpunkt der Exception gesetzt worden sind!) dennoch unbesehen benutzt, werden oft schwer aufzuklärende Folgefehler auftreten.

Die Behauptung, es käme häufig vor, dass eine Methode/Funktion nicht die normalerweise erwarteten Ergebnisse liefern kann, ist für Sprachen, die das Sprachmittel "Exceptions" nicht kennen, falsch. "Normalerweise nicht erwartete Ergebnisse" gibt es bei in diesen Sprachen formulierten Methoden/Funktionen nicht. -- vgl

Christian Morgenstern, "Die unmögliche Tatsache", letzte Strophe:

Und er kommt zu dem Ergebnis: "Nur ein Traum war das Erlebnis. Weil", so schließt er messerscharf, "nicht sein ''kann'', was nicht sein ''darf''."

Natürlich gibt es in jeder Programmiersprache Situationen, wo eine Funktion nicht das tun kann, wofür sie eigentlich gedacht ist, z. B. die erwarteten Output-Parameter? nicht sinnvoll setzen kann. In Sprachen ohne Exceptions kann man dann ersatzweise nur einen entsprechenden Return-Code? zurückliefern. Wenn man jedoch kein Ausnahmeprogrammierer ist, sondern vergesslich, eilig oder einfach schlampig (wie ich), so wird man vielleicht versäumen, nach mehr oder weniger jedem Function-Call? diesen Return-Code? nach allen Regeln der Kunst akribisch auszuwerten und die undefinierten Outputs einfach unbesehen verwenden, was zu Abstürzen oder schwer aufzuklärenden Folgefehlern führen kann. --kg
Daher:

Exception-Handling? ist eine Methode, "Vertragsbrüche" beim Methodenaufruf nicht-ignorierbar zu machen und ihre Behandlung ohne viel Umstand von der unterst-möglichen auf die am besten geeignete Behandlungsebene zu verschieben.

Maßnahmen in Lava:

1. Methoden-Parameter? werden strikt in Input- und Output-Parameter? getrennt; Parameter-Übergabe? "by reference" gibt es nicht.
2. Eine Methode muss jedem nicht-optionalen Output-Parameter? in jedem ihrer Zweige einen Wert zuweisen: wird zur Programmierzeit kontrolliert. (Daneben wird auch verhindert, dass die Function einem Input-Parameter? einen neuen Wert zuweist.)
3. Wenn eine Methode in einem Zweig nicht alle Output-Parameter? erfolgreich setzen kann, so kann dieser Zweig nur mit einem "fail <expression>"-Statement abgeschlossen werden, das eine Exception auslöst: wird zur Programmierzeit erzwungen; der Wert von <expression> definiert das zugehörige Exception-Objekt?. Sein Typ muss durch eine der Klassen beschrieben werden, die in der "throws"-Klausel ("Exception-Spezifikation?") der Methoden-Deklaration? enthalten sind. Anders als in Java muss die Exception-Spezifikation? jedoch keine Exceptions auflisten, die von untergeordneten Methodenaufrufen herrühren können. Vgl. CheckedExceptionsConsideredHarmful.
4. Lava unterstützt Attached Assertions (ähnlich dem "Design By Contract DBC in SpracheEiffel): In der Methoden-Deklaration? kann man Vor- und Nachbedingungen des Methodenaufrufs deklarieren, die bei Verletzung entsprechende Exceptions auslösen. Lava-Klassen? (Interface und Implementation) können mit Invarianten versehen werden, die nach jedem Methodenaufruf gültig bleiben müssen, sonst Exception.

Auf eine "Aufräum"-Klausel "finally" (Java, C#), die unter allen Umständen bei Verlassen des try-Statements ausgeführt wird, haben wir in Lava verzichtet: Generell wird die Lebensdauer von Lava-Objekten? durch Referenzzähler kontrolliert. Dadurch ist gesichert, dass ein Objekt immer zum frühestmöglichen Zeitpunkt automatisch freigegeben wird, nämlich sobald es nicht mehr referiert wird.

Zu diesem wohldefinierten Zeitpunkt wird dann auch automatisch die Finalize-Methode? aufgerufen (die entweder von Klasse "Object" geerbt wird oder handprogrammiert sein kann). Durch expliziten Aufruf von Objekt::Finalize kann ein Objekt vorzeitig unbenutzbar gemacht ("zombifiziert") werden: Jeder nachfolgende Benutzungsversuch löst dann eine spezifische Exception aus.

Ein handprogrammiertes Finalize wird man in Lava nur benötigen, wenn es um die korrekte Freigabe von Betriebssystem- oder anderen Nicht-Lava-Objekten? geht, deren Lebensdauer nicht durch Lava-Referenzzähler? kontrolliert wird.

Ergänzende Anmerkungen: Das versehentliche Benutzen undefinierter Variablen-Werte? (und damit die Haupt-Ursache? von Exceptions) wird übrigens in Lava nicht nur für Output-Parameter?, sondern auch für lokale und Member-Variablen? (durch Programmierzeit-Checks?) verhindert:

1. Eine lokale oder Member-Variable? muss "im gleichen Programmzweig weiter oben" gesetzt werden, bevor sie lesend benutzt werden kann.
2. Ein "Initializer" einer Klasse (~ Konstruktor in Lava) muss jede nicht-optionale Member-Variable? setzen: wird zur Programmierzeit geprüft.
3. Ein Lava-Object? kann nicht als Input-Parameter? an eine Methode übergeben werden, solange es noch nicht vollständig initialisiert ist.
4. Die (lesende) Benutzung von Variablen und Ausdrücken, deren Wert optional ist (also auch null sein kann) an Stellen, wo ein nicht-optionaler Ausdruck erwartet wird, wird durch statische Checks verhindert. Man wird so gezwungen, explizit den Lava-"else"-Ausdruck oder die "ifdef"-Anweisung zu benutzen, um sicherzustellen, dass man nicht versehentlich über undefinierte optionale Ausdrucks-Werte? "stolpert".

1. eine Single-Assignment-Sprache? ist und
2. (als Folge davon) keine Schleifenkonstrukte, sondern nur rekursive Funktionsaufrufe vorsieht.

Siehe dazu auch http://lavape.sourceforge.net/doc/html/RepetComputSamples.htm.

Andere denkbare Maßnahmen, um das irrtümliche Arbeiten mit undefinierten oder semantisch nicht adäquaten Variablen-Werten? unwahrscheinlicher zu machen, die z. B. die Ursache für gewisse gescheiterte Weltraum-Missionen? waren:

Wenn ein Input-Parameter? einer Methode in einem gewissen Wertebereich liegen muss (was beim Ariane5Absturz meines Wissens der Fall war), so müsste ein gewissenhafter Methoden-Programmierer? dies entweder durch eine Assertion (eine Methoden-Vorbedingung?, oder ein Lava-"assert"-Statement, löst bei Verletzung Exception aus) oder durch eine if-Verzweigung absichern, die nötigenfalls eine spezifische Exception auslöst. Zumindest aber sollte eine solche Vorbedingung als Kommentar in der Methoden-Deklaration? ausdrücklich genannt werden, damit man schon zur Programmierzeit auf das Problem aufmerksam wird.

Eine amerikanische Mars-Mission? ist meines Wissens gescheitert, weil Maßeinheiten (yard und meter o. ä.) verwechselt worden waren. Dies könnte man vermeiden, indem man für Zahlen-Parameter? nicht einfach Float-, Double- oder Integer-Typen? benutzt, sondern (sofern diese Basis-Typen?, wie in Lava, normale Klassen sind) daraus abgeleitete Klassen, die die Maßeinheit ausdrücken. Dann wäre die Verwechslung schon zur Programmierzeit als Typ-Fehler? aufgefallen.

Man braucht dann aber auch ein spezifisches Ausdrucksmittel (wie die "scale"-Expressions in Lava), um einen gewöhnlichen Zahlenwert, der vielleicht aus einer mathematischen Funktion (Sinus o. ä.) herauskommt, in einen solchen "dimensionierten" Wert umzuinterpretieren/zu spezialisieren. Siehe dazu Punkt 8 der Release Notes zu Lava 0.6: http://lavape.sourceforge.net/doc/html/ReleaseNotes.htm#R0_6, und das zugehörige Beispiel http://lavape.sourceforge.net/doc/Samples/ScaleUnits.htm.

Zu Exceptions in SpracheLava siehe auch http://lavape.sourceforge.net/doc/html/ExceptionSamples.htm

Exception-Handling? durch Callbacks:

Das "typverzweigende" Exception-Handling? durch typspezifische "catch"-Klauseln ist ja eigentlich unbefriedigend und unerwünscht, weil es das objektorientierte Denken untergräbt.

Das objektorientierte Exception-Handling? durch eine überschriebene "Object::catch"-Methode (s.o.) ist nur dann sinnvoll anwendbar, wenn derjenige, der die Exception behandelt, zugleich die abgeleitete Exceptionklasse "in der Hand hat", also nach seinen Vorstellungenn gestalten kann, insbesondere die überschriebene "catch"-Methode selbst programmieren kann, was meistens nicht der Fall sein wird, da die Exceptionklasse normalerweise von dem Programmierer der gerufenen Methode gestaltet werden wird.

Ein angemessener objektorientierter Umgang mit diesen Fällen kann in Lava dadurch erreicht werden, dass die exception-auslösende Methode unmittelbar vor dem "Werfen" der Exception ein spezifisches "Signal" im Sinne des Lava-Callback-Konzeptes emittiert, für das der Methoden-Aufrufer? eine von ihm programmierte Callback-Methode? abonniert hat, die dann also vor dem formellen Auslösen der Exception auf Grund des emittierten Signals automatisch aufgerufen wird und die eigentliche Exceptionbehandlung übernimmt.

--KlausGünther