ich wollte jetzt Mal brav meine Klasse von std::exception erben lassen. Bei vielen Stackoverflow-Beiträgen stand aber, man sollte doch lieber von den Unterklassen erben.

Jetzt verstehe ich diese aber nicht. std::runtime_error und std::logical_error wären für mich jetzt per se erstmal exklusiv, das geht klar. Aber von std::logical_error erbt ja wiederum std::domain_error und als Beispiel dafür steht bei cplusplus.com/reference ( http://www.cplusplus.com/reference/stdexcept/domain_error/ ) die Angabe einer negativen Zahl für eine Wurzelfunktion. Wenn der Aufruf aber mit Benutzereingaben geschieht, so hat das doch nichts mit der Programmlogik zu tun. Wo liegt mein Denkfehler?

Beste Grüße!

Wenn der Aufruf aber mit Benutzereingaben geschieht, so hat das doch nichts mit der Programmlogik zu tun. Wo liegt mein Denkfehler?

logic_error sagt dir, dass die Programmlogik die Benutzereingabe vorher auf <0 hätte checken sollen. Programme, die sqrt(negativeZahl) aufrufen, fehlt dieser notwendige Check.

Ich bin allgemein der Meinung, dass diese Aufteilung und das ganze std::exception-Design schlecht ist.

Wenn der Aufruf aber mit Benutzereingaben geschieht, so hat das doch nichts mit der Programmlogik zu tun.

Der Funktion ist es egal woher, die Daten kommen. Sie wirft einfach bei falscher Benutzung, basta. Woher soll den sqrt wissen, woher seine Parameter kommen?

Wenn du von Amazon ein Paket bekommst und es ist das Falsche drin, dann schickst du es auch zurueck, egal ob es ein Roboter verpackt hat oder ein Mensch.

Eisflamme schrieb:

... die Angabe einer negativen Zahl für eine Wurzelfunktion. Wenn der Aufruf aber mit Benutzereingaben geschieht, so hat das doch nichts mit der Programmlogik zu tun. Wo liegt mein Denkfehler?

Dein Programm ruft die Wurzelfunktion mit einer negativen Zahl auf, und das ist nicht erlaubt. Daher ist das ein Programmfehler.
Wenn die Zahl aus einer Benutzereingabe kommt, dann ist der Fehler dass dein Programm die Benutzereingabe nicht validiert bevor er damit die Wurzelfunktion aufruft.

Ich bin allgemein der Meinung, dass diese Aufteilung und das ganze std::exception-Design schlecht ist.

Warum? Was insbesondere ist an der Aufteilung in Logik- und Laufzeitfehler schlecht?

aber ist der Exceptionwurf nicht genau die Behandlung der Falscheingabe?

Exceptions haben was mit Ausnahmen zu tun voellig losgeloest von Eingaben.

Warum? Was insbesondere ist an der Aufteilung in Logik- und Laufzeitfehler schlecht?

In welchen Situationen kann man std::logic_error denn sinnvoll einsetzen? Das einzig Vernünftige, was man damit tun kann, ist das Programm sofort zu beenden und einen Log o.Ä. zu schreiben. Nach einem Logikfehler sollte man aber nicht weiterarbeiten.

Ist für mich halt eher ein Fall von assert...

Nach einem Logikfehler sollte man aber nicht weiterarbeiten.

Koennen muessen sollen ... ist vom Anwendungs- und Problemfall abhaengig.

Das einzig Vernünftige ... das Programm sofort zu beenden

Bullshit.

Ist für mich halt eher ein Fall von assert...

assertions haben im Release-Modus keine Wirkung.

BTW, sollte das eine Antwort auf meine Frage sein? Wenn du der Meinung bist, dass Logikfehler als Exceptions sinnlos sind, dann ist doch nicht die Aufteilung der Exceptionhierarchie schlecht, sondern gerade gut. Du kannst den Zweig logic_error dann ja einfach ignorieren.

Etwas, das im Release-Modus nicht vorkommt. Und vor allem etwas, das man nicht sinnvoll zur Laufzeit behandeln kann -- wenn die Programmlogik fehlerhaft ist, wie soll man dann noch weiterarbeiten? Jeder weitere Schritt basiert auf fehlerhaften Annahmen. Man läuft Gefahr, noch mehr Schaden anzurichten, wenn man den Fehler ignoriert. Daher würde ich versuchen, was möglich ist zu retten, und das Programm zu beenden.

Daher würde ich versuchen, was möglich ist zu retten, und das Programm zu beenden.

Und wie machst du das? Sicherlich nicht, indem du den Fehler ignorierst oder mittels assert ein exit auslöst, sondern indem du eine Exception wirfst, die gefangen wird und einen geregelten Abbruch auslöst.

WENN man denn überhaupt abbrechen will.

@logik0r
Die Argumentation ist so alt wie das Thema Fehlerbehandlung in Programmen.
Der Standpunkt ist nicht unsinnig. Er ist aber auch nicht der einzige der Sinn macht. In vielen Fällen ist es besser das Programm fortzusetzen.

Demnach sollte eine invalid_argument-Exception nicht ausgelöst werden, wenn der Benutzer irgendwas eingibt?
~~
Wenn mein XML-Parser also eine invalid_argument-Exception wirft, weil der Benutzer in der Datei rumhantiert hat (was er darf!), aber einen Fehler gemacht hat, dann ist das nicht legitim? Analog zur Wurzelfunktion müsste ich ja hier vorher alles prüfen, damit die Exception nicht geworfen wird, weil die ja sagen würde "falsches Argument" und damit ein Logikfehler wäre. Oder habe ich einen Denkfehler?~~

std::streams kann man so einstellen, dass die bei Falscheingabe eine Exception werfen.

int x;
std::cin >> x;

Benutzer gibt "Hund" ein, Exception fliegt => Das ist aber ein runtime_error. Vom Namen her wäre invalid_argument doch die perfekte Basisklasse. Oder ist "Hund" in dem Kontext kein Argument? Dann finde ich aber invalid_argument als Namen irreführend.

Oder ist "Hund" in dem Kontext kein Argument?

Argumente sind das, was an Funktionen übergeben wird, nicht die Zeichen in irgendeinem Stream. Hier also das x.

Wäre aber trotzdem basierend auf Benutzereingabe, hat nichts mit einem Logikfehler der Software zu tun.

Man läuft Gefahr, noch mehr Schaden anzurichten, wenn man den Fehler ignoriert. Daher würde ich versuchen, was möglich ist zu retten, und das Programm zu beenden.

Niemand redet von Ignorieren, Abbruch ist die letzte Option, aber nie die einzige. Ein konsistenter Zustand der Anwendung ist bei vielen Programmen gefragt, erst wenn dieser nicht mehr hergestellt werden kann, dann ist ein koordinietes Beenden sinnvoll.

Nagut, dann... puh, ich weiß nicht, ob ich die Unterscheidung so toll finde. Schließlich ist logical_error ja auch ein Fehler, der zur Laufzeit geschieht, somit eine Art "runtime_error", auch wenn das Wort es nicht bedeutet.

Mir fällt nicht Besseres ein, aber mir erscheint das einfach überhaupt nicht intuitiv... mein Problem

Wieso soll ich da einen großartigen XML-Check vorsetzen? Regel ist, dass die XML-Datei in Ordnung ist. Ausnahme, dass etwas daran kaputt ist, weil der Benutzer Fehler gemacht hat.

Es ist einfach unnötiger Aufwand irgendwelche Checks drumherum einzubauen, wenn der Parser das selbst macht und mir das mit einer Exception mitteilt. Mehr Code, der fehlerhaft sein kann und der einfach unnötig ist. Genau so sehe ich nicht, wieso ich bei einer Wurzelfunktion nicht einfach die Exception fangen kann, dem Benutzer die Ausgabe gebe, dass das Argument invalide ist und der Ablauf weitergeht... Wo ist das Problem?

Denk nur mal an Betriebssysteme.

Ich denke die wenigsten Leute hätten viel Freude damit wenn das OS sämtliche "logic errors" mit einem BSOD bzw. auch nur dem Abbruch des Prozesses quittieren würde.
Beispielsweise wenn man einen IOCTL an ein Gerät schickt das diesen gar nicht unterstützt.
Oder wenn man versucht in ein File zu schreiben das man nicht schreiben darf.

Das sind Dinge die ein Programm immer vermeiden könnte, aber oft ist es besser es einfach zu probieren und dann zu sehen was passiert. Weil es oft viel unkomplizierter umzusetzen ist, und unkomplizierter ist besser als komplizierter.

Natürlich kann man jetzt sagen dass alles was "von ausserhalb" kommt erstmal validiert werden müsste. Aber es ist oft einfach nicht praktikabel alles vorab erstmal zu validieren. Es ist oft viel praktischer in der Schicht die die Requests von Ausserhalb entgegennimmt nur bestimmte grundlegende Dinge zu validieren, und den Request dann an einen anderen Programmteil weiterzureichen.
Wenn der dann aber sämtliche "invalid argument" Fehler mit ASSERT/abort quittiert, hat man ein Problem.

mMn. muss man in jedem Fall einzeln entscheiden ob es OK ist bei einem bestimmten Fehler eine Exception zu werfen, oder ob es doch besser wäre den Prozess einfach abzubrechen.

Wieso soll ich da einen großartigen XML-Check vorsetzen? Regel ist, dass die XML-Datei in Ordnung ist. Ausnahme, dass etwas daran kaputt ist, weil der Benutzer Fehler gemacht hat ... wenn der Parser das selbst macht und mir das mit einer Exception mitteilt

Nein, Exceptions werden normalerweise nicht fuer diese Art Ausnahmen benutzt. Normalerweise gibt der Parser den Fehler beim Parsen nicht durch eine Exception nach aussen weiter. Bedenke: C++ ist nicht Java, wo dass vielleicht ueblich ist. Exceptions werden fuer unvorhersehbare Dinge benutzt und nicht fuer den Kontrollfluss. Beispiel Netzwerkverbinding: Eine Ausnahmesituation ist, wenn eine bestehende Netzwerkverbindung waehrend einer Transaktion gekappt wird indem der Netzstecker gezogen wird. Selbst dann muss nicht auf Exceptions zurueckgegriffen werden.

Beispiel fuer logic_error: Dynamische Datentyp, der sowohl Strings und Zahlen repraesentieren kann. Operationen auf diesen bspw. + sind nur partiell definiert.

knivil:
Das verstehe ich auch, wobei ich es immer noch schwierig finde die Grenze zu ziehen. Unvorhergesehen ist ja im Grunde nichts, wenn man dafür eine Exception bastelt, denn dann hat man ja dran gedacht. Dein Beispiel für logic_error finde ich gut. Hm, aber für mich ist ein Ausnahmefall auch nur ein anderer Zweig eines Kontrollflusses. Wie gesagt: Meine XML-Datei wird ja eigentlich immer korrekt geparst. Dass die invalide ist, ist für mich unvorhergesehen (zu einem gewissen Maße, siehe Satz 2).

Auch glaube ich dann bei vielen Bibliotheken Konflikte zu sehen. Also RapidXML schmeiß eben in dem Szenario eine Exception, ist das dann "falsch"? Und bei std::cin kann man bei Bedarf auf fehlerhafte Benutzereingabe eine Exception werfen lassen, das ist für mich aber auf derselben Ebene wie eine XML-Datei-Eingabe: wenn der Benutzer bei einer Zahlenerwartung einen String eingibt, ist das für mich genau so Kontrollfluss (oder Ausnahme, je nach Standpunkt) wie bei einer malformed XML-Datei. Dann wäre hier eine Exception ja auch nicht angebracht?

ist das dann "falsch"?

Sicher nicht. Finde ich es gut: Nein. Klar kann man sagen, ist Geschmackssache. Aber manche haben halt einen schlechten Geschmack. Wer definiert guten Geschmack? Hmm, die C++-Community wahrscheinlich.

Unterschied zwischen Benutzereingabe und XML-Datei: Benutzer verschreibt sich viel oefter als dass eine maschinengenerierte XML-Datei fehlerhaft ist. Deswegen ist es legitim, auf Fehler unterschiedlich zu reagieren.

Auch glaube ich dann bei vielen Bibliotheken Konflikte zu sehen

Nun, viele Bibliotheken schmecken eben nicht gut. Aber nicht immer kann man sich ein Gericht von einem 3-Sterne-Koch leisten.

Macht das boost für Deinen Geschmack gut? Irgendworan muss man sich ja ein Beispiel nehmen.