[Python-de] RE: [Python-de] Versuch über die Ausnahmebehandlung

Gerson Kurz Gerson.Kurz at t-online.de
Wed Dec 11 16:37:53 EST 2002


Martin v. Löwis schreibt:

> Da machst Du das ignorieren falsch. Unerwartete Fehler sollten
> grobkörnig ignoriert werden, nicht feinkörnig. Damit kann man während
> des Entwickelns gewisse Klassen unerwarteter Fehler finden und
> eventuelle Bugs fixen, und dann mit geringem Aufwand eine Version
> produzieren, die auch unerwartete Fehler ignoriert.

Vielleicht liegt mein Problem darin, daß ich immer an das Modell denke:
Mehrere Programmteile (unterschiedlicher Firmen) arbeiten zusammen. So ist
das z.B. in unserem Umfeld - wir schreiben Gerätesteuerungen, andere setzen
diese ein. Ich möchte mein API so gerade wie möglich auf *meiner* Ebene
halten, weil ich aus leidgeprüfter Erfahrung weiß, was eine
"Problemeskalation durch den Vorstand" ist.

> Dann kannst Du err_open benutzen, und den Fehlercode abfragen. Das
> geht auch ein bisschen allgemeiner:
>
> def err(func, *args):
>   try:
>     return func(*args)
>   except:
>     return None

Du wirst lachen - sowas ähnliches habe ich auch (heisst bei mir "always"),
nur gebe ich ein tupel (result, errorcode) zurück, weil ich nicht wissen
kann, ob "None" ein gültiger Rückgabewert oder der Fehler ist.

Daß es den Code nicht schöner macht, brauche ich nicht zu erklären.

> Wie wäre es mit
>
> try:
>   cfg_open()
>   value = cfg_get(name, value) # Was bedeutet hier eigentlich der
>                                # value-Parameter?
> except CfgCouldNotOpen:
>   return value
> except CfgKeyError:
>   try:
>     cfg_set(name, value)
>   except CfgPermissionDenied:
>     pass
>
> cfg_close()
> return value

Das ist zugegeben lesbarer, mich würde jetzt nur noch stören, daß ich nur
explizit diese beiden Exceptions wissen muss. (Ich musste übrigens den Code
zweimal lesen, um zu erkennen, daß cfg_close() nicht aufgerufen wird, wenn
cfg_open() fehlschlägt).






More information about the Python-de mailing list