Vergleich und Fehlerabfang in einem möglich?

[snafu]

Bezüglich der Typprüfungen von Kommandozeilenargumenten hier der passende Abschnitt aus der `argparse`-Doku:
https://docs.python.org/3/library/argparse.html#type

Grundsätzlich könnte man an dieser Stelle auch schon Werteprüfungen vornehmen, um diese schon ganz weit "oben" im Programm abzufangen. Der Nachteil ist dann allerdings, dass man in den tiefen des Programms, wo man den Wert tatsächlich verwendet, entweder die Werteprüfungen weggelassen wird oder nochmals vorgenommen wird, was beides kein allzu guter Porgrammierstil ist. Daher würde ich die beiden Arten von Prüfungen idealerweise getrennt vornehmen lassen.

Eine Exception (z.B. `ValueError`) aus den Tiefen des Programms kann übrigens immer noch hochgereicht werden und weiter oben als Fehlermeldung auf der Konsole dem Benuter präsentiert werden. Ich hatte das bereits auf Seite 1 dieses Threads an einem Minimalbeispiel gezeigt.

[mutetella]

@BlackJack
Mir erschien die Behandlung aller Fehler an dem Ort, an dem sie letztlich auftauchen, am Sinnigsten. Aber ok, snafu's Erklärungen und Dein `‽` überzeugen mich langsam...

[jerch]

@mutetella:
Ich würd das davon abhängig machen, wie gekapselt werden soll. Wenn Du ein Funktion schreibst, die garantiert nur mit Typ XY im Wertebereich a..b umgehen kann, dann ist es doch schon ein Fehler, da was anderes zu übergeben. Hinzu kommt noch die Frage, ob bei Anwendungsparametern dem Nutzer Pythonfehlermeldung zuzumuten sind. Diese würde ich eher selbst nochmals kapseln, also abfangen und dem Benutzer eine für ihn verständliche Fehlerbeschreibung geben und nicht den Traceback vor die Füße knallen. Bei API-Nutzern (Programmierern) ist letzteres IMHO ausreichend.

[BlackJack]

@mutetella: Wo ist denn der Ort wo der Fehler auftaucht wenn der Benutzer keine ganze Zahl oder eine negative Zahl angibt wo er laut Benutzerdokumentation eine positive ganze Zahl angeben soll? Der ist doch an der Stell wo die Benutzereingabe validiert wird, also so ziemlich direkt nach der Eingabe. Denn man will in der Regel ja zwei Sachen erreichen: Valide Daten und Fehlermeldung für den Benutzer so schnell wie möglich und nicht erst wenn zig Rechnungen durchgeführt wurden, womöglich mit falschen Daten und umsonst weil es irgendwann wegen falscher Daten nicht weitergeht.

[mutetella]

@BlackJack
Also würdest Du nicht nur die Typprüfung sondern auch die Prüfung des Wertebereiches bereits im Parser vornehmen?

[BlackJack]

@mutetella: Da ist jetzt die Frage was Du als Parser bezeichnest. Auf jeden Fall gehört IMHO das prüfen von Benutzereingaben mit in die Schicht die mit dem Benutzer kommuniziert, also nicht in die Programmlogik. In GUIs oder bei Webformularen ist das ja üblicherweise die Validierung der Eingaben. In der Programmlogik kann und sollte man soweit sinnvoll auch prüfen, aber weil der Programmierer Fehler machen kann, nicht weil der Benutzer falsche Eingaben machen kann.

[snafu]

Das kommt sehr auf den Anwendungsfall an, würde ich sagen. Ein paar einzelne Argumente würde ich nach der Konvertierung zu passenden Typen stumpf durchreichen bis es ggf wegen falschen Werten knallt und mir die Exception dann hochreichen lassen. Wenn es aber sehr viele Werte sind und man ohne großen Aufwand schnell feststellen kann, dass Fehler in den Daten vorhanden sind, dann würde ich die schnell melden lassen, anstatt aufwändig mit den validen Daten zu rechnen bis es zum Fehler kommt.

Möglicherweise solltest du dich im Hinblick auf die Verbesserung deines Programmierstils mal mit dem Weiterreichen (engl. Begriff: Delegation) von Fehlern und Werten beschäftigen. Gerade Progammiersprachen mit eingebauten Exceptions ermöglichen da Vorgehensweisen, die einem insbesondere bei Fehlermeldungen das Leben erleichtern können, wenn man sie sinnvoll einsetzt (Stichwort: das bereits mehrfach erwähnte Hochreichenlassen eines Fehlers).

Ich will jetzt nicht oberlehrerhaft rüberkommen, aber ich habe den Eindruck, dir fehlt noch ein bißchen die Fähigkeit, Progammabläufe als getrennte Einheiten zu strukturieren bzw so im Code abzubilden. Denke dir große Programme als Fachabteilungen in einem Unternehmen und vertraue einfach darauf, dass die Fachbereiche dir schon die richtigen Antworten geben werden. Bei einem Projekt in kompletter Eigenregie definierst du das Verhalten jeder Fachabteilung. In großen Teams (meistens: beruflich) vertraust du darauf, dass dein Kollege die "Fachabteilung" geeignet "geschult" hat und dass du deren Aussagen zweifelsfrei übernehmen kannst.

Ich hoffe, das war jetzt nicht zu wirsch...

[mutetella]

Ich hoffe, das war jetzt nicht zu wirsch...

Quatsch! Überhaupt nicht! Das hilft mir sehr weiter!

Vielen Dank @all! Und jetzt schau' ich mal, dann seh' ich schon...