Vergleich und Fehlerabfang in einem möglich?

[mutetella]

@BlackJack
Ja schon, aber den kann ich ja dann nicht innerhalb ``__init__()`` abfangen und mit einer eigenen Meldung versehen... Beantwortet das vielleicht schon meine Frage an snafu, will heißen, dass das z. B. ein Fehler wäre, den der Parser behandelt?

[BlackJack]

@mutetella: Warum willst Du das denn mit einer eigenen Meldung versehen? Wenn Du das grundsätzlich haben möchtest, dann müsstest Du diesen Code ja in *jeder* Funktion und Methode schreiben. Das erscheint mir ein bisschen, äh, ehrgeizig. Kann sein das die Standardmeldung etwas präziser sein könnte (also zumindest soweit es so eine Funktionssignatur mit Namen gibt, das ist bei in C implementierten Funktionen ja nicht zwingend der Fall), aber meinst Du nicht die Meldung das zu wenig Argumente übergeben wurden, reicht dem Programmierer nicht aus? Oder versuchst Du hier mit Ausnahmen Fehler die der *Benutzer* gemacht hat für den Benutzer zu ”beantworten”? Dafür sind Ausnahmen nicht gedacht.

[mutetella]

[...] reicht dem Programmierer nicht aus?

Doch klar, Programmierer sollten sich weiterhelfen können...

[...] für den Benutzer zu ”beantworten”?

Ja genau! Ich möchte meine Anwendung mit Fehlermeldungen versehen, die dem Benutzer so weit als möglich Hilfestellung geben.

Dafür sind Ausnahmen nicht gedacht.

Ja aber was/wie denn dann?

[BlackJack]

@mutetella: Wenn diese Klasse mit einem Argument zu wenig aufgerufen wurde, dann hat doch der Programmierer etwas falsch gemacht und nicht der Benutzer. Ich verstehe die Frage darum nicht so ganz‽

[snafu]

@mutetella
Was das Parsen von Kommandozeilenargumenten angeht, so empfehle ich einen Blick in die `argparse`-Dokumentation. Da kann man frühzeitig die Argumente in die erwarteten Datentypen konvertieren lassen und die Fehlerausgabe im Falle von nicht konvertierbaren Argumenten durch die `argparse`-Bibliothek erledigen lassen.

Und die so erhaltenen Datentypen würde ich an die internen Klassen und Funktionen deines Programms weiterleiten. Da kann man dann bei Bedarf noch Werteprüfungen vornehmen (z.B. nicht-negativ) sowie andere Plausibilitätsprüfungen durchführen und mit Exceptions reagieren.

Der Parser müsste also Informationen haben, die ihn selbst gar nicht betreffen, um z. B. den von einer Klasse erwarteten Typ im Vorfeld zu prüfen.

Und wo ist das Problem? Der Parser weiß so oder so nicht, was anschließend mit dem von ihm gelieferten Ergebnis passiert. Wozu sollte er das auch wissen müssen?

Du als Programmierer sollst dem Parser doch sagen, welche Argumente erwartet werden, von welchem Typ sie sein sollen, sowie ggf ungültige Kombinationen von Argumenten definieren. Der Parser verrichtet als abgeschlossene Einheit dann die Interpretation der Eingabe und gibt dir im Falle eines fehlerfreien Durchlaufs eine Struktur von Argumenten zurück, die an andere Programmteile zur weiteren Verarbeitung übergeben werden können.

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