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

[lunar]

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.

[helduel]

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...

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]

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

[helduel]

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.

[snafu]

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]

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.