*grübel* ... *grübel* ... habe nun meinen Post 3-mal begonnen, und irgendwie immer noch nicht so den richtigen Ansatz gefunden.
Was die
ERROR_CODES Variante angeht, so nutzte ich Error Codes eher als finale Fehlerindikation wenn ich mein Programm in einem Fehlerfall abbrechen lasse. In solchen Fällen ist es für ein z.B. aufrufendes Programm von Vorteil, wenn dieses an Hand von Codes die Fehlerfälle unterscheiden kann (und nicht die Fehlermeldung erst geparst werden muss ... was im Falle von "Language-Support" schon echt eine grausame Aufgabe sein kann).
Sowas erfordert natürlich eindeutige Codes, eine ausführliche Dokumentation dieser sowie vielleicht eine Anlehnung an typische, bekannte Codes (z.B. in Bezug auf das verwendete Betriebssystem, o.ä.).
Bsp.:
Code: Alles auswählen
def abort(text, error_code):
error_msg = "ERROR: %s" % text
sys.stderr.write(error_msg)
sys.exit(error_code)
# abort("File '%s' not found" % 'test.txt', 2)
# abort("Internal Error", -1)
# abort("Access denied", 401)
# ...
Intern finde ich die Verwendung von Error Codes persönlich eher witzlos ... sie sind einfach schwer zu lesen, schwer nachzuverfolgen und noch schwerer zu pflegen.
Funktionatlitäten sollten so gestrickt sein, dass wenn sie mit Rückgabewerten arbeiten auch entsprechend eindeutige Werte zurückgeben können.
Es macht meiner Erfahrung nach mehr Sinn z.B. eine Methode
Code: Alles auswählen
def is_system_active(self):
if self.status in ['inaktiv', 'off', 'schlafend']:
return False
if self.energy <= 0:
return False
return True
z.B. zu verfassen, und mit dem boolschen Erfolgsindikation weiter zu arbeiten, als mit Fehlercodes mit mehr als
Wahr oder
Falsch verarbeiten zu wollen.
Für mehr Komplexität in Bezug auf die Fallunterscheidung gibt es ja schließlich immerhin ja noch die Methodik des
Zustandsautomaten.
Was hingegen
Exception-Handling angeht, so ist dies auch immer wie mit einer Schwingtür:
Läufs't zum richtigen Zeitpunkt durch ... wunderbar, andernfalls schlägst dir im ungünstigen Falle ne blutige Nase.
Betreibt man Exception-Handling "übersichtlich" und sowohl im Wissen darüber welche Exceptions wo genau geworfen werden können, sowie auch der Tatsache der Anwendung des expliziten Exception-Catchings (und nicht der bequemen und einfachen Anwendung des "Catch-All"-Prinzips
) ... dann ist es manchmal echt ne tolle Sache.
In einem Projekt ist mir einmal untergekommen, dass ein spezielle Fehlerklasse (nennen wir sie mal "AppError") mit einem Fehlertext inform eines Codes, sowie Fehlertext-Paramtern geworfen wurde. Der Fehlercode holte sich den Fehlertext aus der Datenbank und füllte dort Platzhalter mit den erwähnten Fehlertext-Paramtern aus ... abgefangen wurde "nur" diese spezielle Fehlerklasse von dem verantwortlichen XML-RPC-API oder WebApp-API Modul.
So konnte aus dem Prozess eines Aufrufes seitens des Benutzer herraus gleich einer Fehlernachricht angezeigt werden, ohne komplizierte Rückgabepfade durchlaufen zu müssen.
Es gibt in meinen Augen also halt Architekturen und Stellen wo gerade Exceptions DIE Lösung schlecht hin sind.
Was natürlich totaler Bullshit hingegen ist, dass ist der Versuch Exception als finale Fehlerindikation im Rahmen des Programmabbruches zu verwenden, welche externe (vielleicht gar in anderen Programmiersprachen geschriebene) Programme oder ein End-Benutzer informieren sollen.
Code: Alles auswählen
c:\daily_backup.exe
[2006-07-30 01:24] Backup is running ...
[2006-07-30 01:25] Prepare path-copy: "d:\Eigene Dateien" ...
Traceback (most recent call last):
File "<stdin>", line 25, in copy_path
NameError: name 'ValuError' is not defined
"... hm ... äh ... jap ... omg ... Huston?"
Zurück zur
Umfrage fehlt mir allgemeinen deswegen ein Punkt für beides gleichermaßen, wenn als Error_Codes auch ein einfaches
True or
False gillt
.
Gruß,
>>Masa<<