[Python-de] Versuch über die Ausnahmebedingung

Gerson Kurz Gerson.Kurz at t-online.de
Tue Dec 10 22:34:11 EST 2002


Ich möchte die derzeitige vorweihnachtliche Stille auf python-de stören und
mal kundtun, was genau mich an Exceptions stört. Folgendes Beispiel:

------------- (snip here) ----------

def config(name, value):
    if cfg_open():
        value = cfg_get(name, value)
        cfg_set(name, value)
        cfg_close()
    return value

print config("Beispiel", 123)

------------- (snip here) ----------

Erklärungen dazu:

- Ich möchte mit der Funktion einen benannten Konfigurationsparameter
auslesen.
- Der Parameter soll einen Default-Wert haben (den ich beim Aufruf mit
angebe).
- Der Parameter soll in der Konfiguration angelegt werden, wenn er noch
nicht existiert
- Wenn der angemeldete User keine Screibrechte auf der Konfiguration hat, so
kann es doch gut sein, daß er Leserechte hat.
- Wenn die Konfiguration nicht geöffnet werden kann, will ich den
defaultwert haben.

Das obige Beispiel läßt sich ungefähr so mit den Windows Registy-Funktionen
leicht abbilden. Alle Funktionen liefern einen Fehlercode; schlägt
QueryValue-Funktion (entspricht cfg_get() in obigem Beispiel), ändert sie
den Parameterwert nicht; schlägt SetValue-Fehl, gibt es halt einen
Fehlercode, usw. Obiger Pseudocode ist also nicht völlig realitätsfern.
Bitte, wenn einer an dieser Stelle als Einwurf nur "Das Konzept ist kaputt"
hat, ----> da is der Ausgang.

[Ich habe das tatsächlich mit _winreg gemacht, aber hier im Beispiel
Pseudofunktionen erwähnt, da mir bewusst ist, daß hier eine Reihe von
nicht-Regianern mitliest]

OK, meine Probleme mit dem ganzen:

1) Ich kann schlecht schreiben:

try:
    cfg_open()
    value = cfg_get(name, value)
    cfg_set(name, value)
    cfg_close()
except:
    # was tun ???
return value

Weil, ich weiß ja nicht, welche der vier Funktionen eine Exception geworfen
hat. Beispielsweise kann es ja sein, daß der cfg-Wert noch nicht existiert
(cfg_get schmeisst eine Exception), und erst mit cfg_set angelegt wird.

2) Gut, ich könnte die Exception auswerten. Ich schreibe also:

try:
	...
except exceptions.Exception, e:
      behandle(e)

Das schlägt fehl, wenn einer irgendwo

raise "irgendwas"

stehen hat. Sprich, DER AUFRUFENDE CODE MUSS WISSEN, WAS DER AUFGERUFENE
CODE FÜR EXCEPTIONS WERFEN KANN, egal wie tief dieser verschachtelt ist und
was der seinerseits wieder für code anzieht. 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.

3) Eine Lösung könnte so aussehen:

try
    cfg_open()
except:
    return value
try:
    try:
        value = cfg_get(name, value)
    except:
        pass
    cfg_set(name, value)
finally:
    cfg_close()
    return value

Ich weiss nicht, ich weiss nicht, da sag noch einer, Exception Handling
würde in einfacherem (und lesbarerem) Code resultieren... Abgesehen davon,
daß ich hier noch gar keine Protokollfunktion eingebaut habe (In meinen
C-Programmen einfach ein wegloggen des HRESULTs, hier müsste ein
kompliziertes Auswerten der Exception stehen, inkl. der bei (2) angemerkten
Einschränkungen.

4) Zusammenfassend: Mich stört

a) daß ich wissen muß, dass UND WELCHE Exceptions eine Funktion wirft
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.
















More information about the Python-de mailing list