überprüfen, ob sys.argv[1] vorhanden

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
lunar

Mittwoch 15. Oktober 2008, 09:31

Nun ja, ich würde Kommandozeilenargumente ja mit etwas anständigem wie argparse parsen, dann übernimmt der Parser die Überprüfung ;)

Ich halte es mit dem Zen: "Better explicit than implicit". Ausnahmen sind nicht explizit. Beim Anfangen eines IndexError steht nirgendwo explizit, wie viele Elemente man erwartet. Mehr noch, es ist ja per definitionem nicht mal sicher, dass man tatsächlich den IndexError des Listenzugriffs abfängt. Ein zu großzügiger try-Block kann folglich zu logischen Fehlern führen.
Benutzeravatar
helduel
User
Beiträge: 300
Registriert: Montag 23. Juli 2007, 14:05
Wohnort: Laupheim

Mittwoch 15. Oktober 2008, 10:00

lunar hat geschrieben:Nun ja, ich würde Kommandozeilenargumente ja mit etwas anständigem wie argparse parsen, dann übernimmt der Parser die Überprüfung ;)
Das sowieso, aber wenn wir schonmal dabei waren... ;-)
lunar hat geschrieben:Ich halte es mit dem Zen: "Better explicit than implicit". Ausnahmen sind nicht explizit. Beim Anfangen eines IndexError steht nirgendwo explizit, wie viele Elemente man erwartet. Mehr noch, es ist ja per definitionem nicht mal sicher, dass man tatsächlich den IndexError des Listenzugriffs abfängt. Ein zu großzügiger try-Block kann folglich zu logischen Fehlern führen.
Zu großzügig sagt aber schon was aus: Er ist zu großzügig. Mit dem else-Block kann man den try-Block aber auf's Wesentliche reduzieren:

Code: Alles auswählen

mylist = get_list_from_somewhere()
try:
    foo = mylist[1]
except IndexError:
    do_something()
else:
    do_something_with_list(foo)
Wieviele Elemente erwarte ich? Mindestens zwei. Klar, ich sage nicht, dass ich ein drittes erlaube oder verbiete. Aber das interessiert hier auch gar nicht. Wenn das wirklich so wichtig ist, dann muss ich natürlich besser prüfen. Aber das hängt vom Fall ab. Diese Variante ist IMO für diesen Fall nicht weniger explizit als ein "if len(mylist) == 2" oder "if len(mylist) > 1". Und der IndexError kann nur von meinem Listenzugriff kommen.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 15. Oktober 2008, 10:05

helduel hat geschrieben:Und der IndexError kann nur von meinem Listenzugriff kommen.
Nicht unbedingt, denn wenn mylist keine Liste ist, kann der Indexzugriff durch irgendwas überschrieben werden, was dann zwar exisiteren kann, aber aus einem anderen Grund einen IndexError wirft ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
helduel
User
Beiträge: 300
Registriert: Montag 23. Juli 2007, 14:05
Wohnort: Laupheim

Mittwoch 15. Oktober 2008, 11:03

Leonidas hat geschrieben:
helduel hat geschrieben:Und der IndexError kann nur von meinem Listenzugriff kommen.
Nicht unbedingt, denn wenn mylist keine Liste ist, kann der Indexzugriff durch irgendwas überschrieben werden, was dann zwar exisiteren kann, aber aus einem anderen Grund einen IndexError wirft ;)
Überredet. Auf der anderen Seite kann auch __len__ überschrieben worden sein und die gibt mir jetzt irgendeine Zahl zurück, die gar nichts mit meinen Elementen zu tun hat. Dann krieg ich trotz Check einen IndexError geworfen, den ich gar nicht abgefangen hab, weil ich ja prüfen tu' und so. :twisted:
Benutzeravatar
snafu
User
Beiträge: 5440
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Mittwoch 15. Oktober 2008, 13:55

helduel hat geschrieben:Also ich sehe Exceptions, wie der Namen schon sagt, als Ausnahmen. Das sind nicht zwingenderweise Fehler. Und wenn ich eine Ausnahmesituation habe, dann muss ich sie anders behandeln als den Rest, was durchaus eine weitere Funktionalität mit sich bringen kann.
In meinen Augen wird in diesem Fall zuerst der eine (Standard-)Weg probiert und wenn der nicht funktioniert (also eine Exception wirft) werden alternative Wege versucht. Das fällt für mich (bin allerdings nicht wirklich von Fach) unter Fehlerbehandlung (diese muss ja nicht zwingend aus einer Fehlermeldung bestehen). Weitere Funktionalität wird damit jedenfalls nicht geboten. Der User möchte als Ergebnis das zurückbekommen, was ihm die Doku beschreibt, egal wieviele Versuche das Programm intern gebraucht hat. Zumindest sehe ich das so.
BlackJack

Mittwoch 15. Oktober 2008, 14:22

Ich denke man sollte hier auch berücksichtigen, dass es sich um Daten handelt, die ein Benutzer eingibt. Die sollte man in der Regel so früh wie möglich auf Plausibilität und Fehler prüfen.

Was die Beschränkung des ``try``-Blocks betrifft: Man hat oft mehrere Argumente und da müsste man dann statt einmal am Anfang auf die richtige Anzahl zu prüfen und entsprechend zu reagieren, bei jedem Zugriff auf die Argumente darauf reagieren. Das macht den Code complizierter als wenn man einmal am Anfang auf Fehler prüft.
Antworten