[Python-de] RE: [Python-de] Re: [Python-de] Versuch über die Ausnahmebedingung

Gerson Kurz Gerson.Kurz at t-online.de
Wed Dec 11 15:22:55 EST 2002


Martin v. Löwis schrub am December 10, 2002 10:54 PM

> Ausnahmen, die nicht zum
> normalen Betriebsmodus gehören (wie etwa AttributeError) sollte gar
> keiner behandeln - es handelt sich schlicht um Programmfehler.

Also, ich möchte das nicht persönlich formulieren, aber: das ist akademisch
gedacht. Man kann in der Theorie sagen: Programmfehler sollen das Programm
beenden, aber in der Praxis soll das verd*mmte Programm weiterlaufen,
solange es geht.

Stell dir vor, ein Bordcomputer im Flugzeug stürzt ab, weil irgendjemand in
einer völlig unwichtigen Nebenfunktionen einen Fehlercode nicht abgefragt
hat -> klar, das war ein Fehler, und der Fehler sollte bereinigt werden, und
solange man in der Debugumgebung ist, ist es auch praktisch das assert ==
exception, aber wenn ich über dem Atlantik schwebe, dann soll bitteschön der
Bordcomputer sich nicht einfach beenden, "damit ich den Fehler finden kann".
Und wer behauptet, er habe in einer einigermaßen komplexen Umgebung
sämtliche möglichen Situationen im Griff, der lügt. (Erste Stunde
Informatikstudium, Programmieren 1: Jedes Program hat Fehler.)

Anderes Beispiel: Wir programmieren Hardware. Es gibt Board-Revisionen. Wenn
ich mich auf den Standpunkt stelle: da ist die Dokumentation, alles was um
ein Haar davon abweicht, wird das in assert geklammert und das Programm
beendet sich - habe ich sehr schnell sehr viele sehr stehende Maschinen
draussen im Feld. Es kann sein, daß ich damit die Wirtschaft in Gestalt des
Techniker-Serviceunternehmens ankurbel, aber mein Gehalt wird darunter
leiden! (Es könnte den Seiteneffekt haben, daß endlich ein Gesetz gemacht
wird, welches es IBM verbietet, eigene Hardwareprotokolle zu definieren,
aber das ist eine andere Geschichte).

> > Ich weiss nicht, sehr nach OOP
> > klingt das für mich nicht. Für mich ist die Lösung "Fehlercode über
> alles"
> > immer noch anziehender.
>
> Ausnahmen bieten Dir alles, was Du mit Fehlercodes auch bekommst, und
> zusätzlich die Sicherheit, das Fehler, die im normalen Betrieb auftreten
> können, nicht ignoriert werden.

Mein Punkt ist hier: manchmal macht es Sinn, gewisse Fehler zu ignorieren,
und *da* muss ich dann ewigen Aufand betreiben.

> > a) daß ich wissen muß, dass UND WELCHE Exceptions eine Funktion wirft
>
> Wie unterscheidet sich das von Fehlercodes? Um zu wissen, ob eine
> Funktion erfolgreich war, musst Du auch die Dokumentation der Funktion
> lesen und verstehen, wie sie ihre Fehler mitteilt (Rückgabewert 0,
> Rückgabewert != 0, Rückgabewert < 0, Ausgabeparameter, usw.)

Der Unterschied ist der Unterschied zwischen

if open():
	tuwas()
else:
	tuwasanderes()

und

try:
	open()
	tuwas()
except:
      tuwasanderes()

Es tut mir leid, ich finde das obige Beispiel besser.

Ich habe den Eindruck: Exception Handling ist ein Erziehungsmaßnahem für die
Leute, die immer keine Rückgabewerte abgefragt haben. Fein! Solche Leute
gibt es, und sie sollten erzogen werden. Aber ich *frage* meine
Rückgabewerte ab, dann möchte ich sie bitte auch abfragen können und nicht
mit in die Erziehungsmaßnahmen zwangsweise eingebunden werden.

(Das ist ähnlich wie die Geschichte mit der Garbage Collection - es tut mir
leid, mein letztes Speicherleak ist schon Jahre her, es handelte sich um 12
Bytes, die alle halbe Stunde dazukamen, und ja: ich überprüfe regelmäßig das
Speicherverhalten meiner Programme, das geht mit einem billigen memorybuild
wunderbar, und ja, die Programme sind in C++ und tatsächlich bei diversen
Endkunden auf der Welt im Einsatz).

> > b) daß es nicht einfach ist, einzelne Funktionen "die Fehlschlagen
> dürfen"
> > mit Funktionen "die in der Richtigen Reihenfolge aufgerufen werden
> müssen"
> > zu mischen, wenn einem potentiell Exception Handling dazwischenfunkt.
>
> Das Argument verstehe ich nicht. Welches Deiner Beispiele belegt es?

Das Beispiel 3? Bitte, sei ehrlich, die Lösung (die mit den vier Excepts, wo
ich dann am Ende vielleicht auch noch die Exceptions einzeln in den vier
Fällen auswerte) schaut Scheisse aus. Man kann ja Exceptions mögen oder
nicht - der Code war Dreck. Punkt.

Die "Fehlercodeversion" ist wie gesagt total simpel:

- Wenn der Open nicht klappt, liefer ich den Default (egal, was das für ein
Fehler ist)
- Wenn der GetValue nicht klappt, wird die Variable nicht verändert
- Wenn der SetValue nicht klappt, hat der Nutzer halt keine Rechte
- Wenn der Close nicht klappt, ist es mir ehrlich gesagt egal das trace ich
weg & aus is.

Keiner der vier genannten Fehlersituationen ist es wert, ein
"lebenswichtiges" (nicht wirklich) Programm einfach zu runterzufahren, blos
weil ein Konfigparameter nicht existiert oder nicht geschrieben werden
konnte. Die Konfiguration kann mich mal, wichtig ist daß das Programm an
sich funktioniert.

Nix für ungut,
Gerson








More information about the Python-de mailing list