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. _______________________________________________ Python-de maillist - Python-de@starship.python.net http://starship.python.net/mailman/listinfo/python-de
participants (6)
-
Georg Mischler
-
Gerson.Kurz@t-online.de
-
Juergen Hermann
-
Martin v. Löwis
-
martin@v.loewis.de
-
Walter Dörwald