bool || void

[iTrodan]

Ich habe da mal ein kleines Beispielprogramm geschrieben:
Pastebin.com

Kònnte man nicht rein theoretisch diese Zeilen weglassen?

int lastError;
 
void printError(int error)
{
        if (error == 1)
                std::cout << "init failed" << std::endl;
        else if (error == 2)
                std::cout << "doStuffA function call 1 failed" << std::endl;
        else if (error == 3)
                std::cout << "doStuffA function call 2 failed" << std::endl;
        else if (error == 4)
                std::cout << "doStuffB failed" << std::endl;

[Nightblizard]

In dem Fall schon, ja. Jedoch wirst du etwas in der Richtung brauchen, wenn die Funktion mit verschiedenen Fehlercodes fehlschlagen kann und du nicht nach jedem Funktionsaufruf die Fehlerbehandlung durchführen möchtest (was totaler overkill wäre).
Kannst das gerne mal entfernen (bzw. den Aufruf der Funktion durch die Ausgabe ersetzen) und dann nochmal laufen lassen. Ich denke aber nicht, dass das einen nennenswerten Unterschied in diesem Fall macht.

Glaub mir, du möchtest das so einfach nicht machen. Wenn du das erste mal mit einer C-API gearbeitet hast, dann wirst du sehen warum das absolut unschön ist. Und wie gesagt, Performance ist erst dann ein Problem, wenn dir das ein Profiler gesagt hat.

[MrSm!th]

Originally Posted by Mostey

Zum Beispiel? Fehlermeldungen sicherlich nicht.

Wenn du das so siehst, gibt es noch viele andere Indikatoren um Fehler festzustellen. Eine LastError Variable ist sowas von unnötig und ineffizient, wenn man Exceptions nutzen kann aber das brauche ich dir ja nicht erklären.

Situationsabhängig.
Wenn du mit C interagieren musst, hast du sowieso keine Wahl.

Originally Posted by Nightblizard

Das ist Unsinn und in der Praxis ist oft sogar das genaue Gegenteil der Fall!
Ich habe da mal ein kleines Beispielprogramm geschrieben:


Im Release Modus mit Visual Studio 2013 compiliert bekomme ich folgendes Ergebnis:



Wer sich nun fragt warum die "Performancefresser" schneller sind: die Antwort darauf ist relativ simpel.
Durch all die ifs in dem Code, die du einfügen musst um sicher zu gehen, dass nirgens eine Funktion fehlgeschlagen ist, fressen wesentlich mehr Performance als ein einzelnes throw das jemals könnte!
Zusätzlich dazu blähen dir die ifs den Code dermaßen stark auf, dass du weit mehr als das doppelte an Code schreiben musst, um ein ansatzweise gleichwertiges Ergebnis zu bekommen. Das führt dann dazu, dass dein Code nicht nur schwerer zu warten und zu lesen wird, er wird auch gleich sehr viel fehleranfälliger!

Dass Exceptions dein Programm langsamer machen ist alter Aberglaube der C Fanatiker und - vorausgesetzt man macht es richtig - in der Praxis sind sie meistens sogar schneller, weil sie extrem viel overhead aus dem Code raus nehmen.
Und selbst wenn sie langsamer sein sollten, alleine schon druch den Gewinn an Lesbarkeit in deinem Code sollte man immer zuerst auf sie zurückgreifen, denn Performance ist erst dann ein Argument, wenn du mit einem Profiler dein Programm überprüfst und dann als Ergebnis diese eine throw Anweisung aufgeführt wird.

Falsch, meine Aussage wurde lediglich nicht richtig aufgefasst. Wann man was nehmen sollte ist situationsabhängig. Es gibt zahlreiche Arten von "Fehlern" und nicht jeder ist einer, der bis auf den obersten Layer hochbubblen muss. Exceptions heißen nicht umsonst Exceptions/Ausnahmen. Es gibt "Fehler", mit denen rechnet man fast schon immer, sprich es würde fast immer eine Exception geworfen werden. Tatsächlich gibt es try-catch Konstrukte, die nichts anderes als ein langsameres if-else darstellen. Genau solche Fehlnutzungen von Exceptions sorgen dafür, dass manche ganz Abstand von ihnen nehmen.
Ich bin selbst ein großer Fan von Exceptions ich bin mir ihrer Eleganz bewusst. Aber zu sagen, sie wären grundsätzlich immer einem einfachen bool vorzuziehen ist einfach Unsinn. Es gibt keine Patentlösung für alles. Nicht umsonst gibt es im .NET Framework auch die TryParse Methoden, die eben nicht schmeißen, sondern false zurückgeben, wenn die Input sich nicht parsen lässt. User-Input ist nämlich so eine Sache, bei der es öfters mal Probleme (DAU) gibt und da ist nicht immer eine Exception sinnvoll oder gar elegant.

Ganz nebenbei gibt es auch Fälle, in denen sind nähere Informationen gar nicht von Belang. Entweder es hat geklappt oder nicht.

p.s. Auch das Argument mit der Lesbarkeit hat 2 Seiten. Ein Nachteil von Exceptions ist nämlich auch, dass ein Ausführungspfad erstmal unsichtbar wird. Man sieht einer Anweisung nicht mehr unbedingt an, ob da etwas schiefgehen kann.
p.p.s. Konstruierte Beispielprogramme sind immer so eine Sache. Ich kann nun auch ein Programm gezielt so schreiben, dass Exceptions schlechter dastehen. Macht nur wenig Sinn, weil beide Varianten ihre Daseinsberechtigung haben.

[Nightblizard]

Originally Posted by MrSm!th

Falsch, meine Aussage wurde lediglich nicht richtig aufgefasst. Wann man was nehmen sollte ist situationsabhängig. Es gibt zahlreiche Arten von "Fehlern" und nicht jeder ist einer, der bis auf den obersten Layer hochbubblen muss. Exceptions heißen nicht umsonst Exceptions/Ausnahmen. Es gibt "Fehler", mit denen rechnet man fast schon immer, sprich es würde fast immer eine Exception geworfen werden. Tatsächlich gibt es try-catch Konstrukte, die nichts anderes als ein langsameres if-else darstellen. Genau solche Fehlnutzungen von Exceptions sorgen dafür, dass manche ganz Abstand von ihnen nehmen.
Ich bin selbst ein großer Fan von Exceptions ich bin mir ihrer Eleganz bewusst. Aber zu sagen, sie wären grundsätzlich immer einem einfachen bool vorzuziehen ist einfach Unsinn. Es gibt keine Patentlösung für alles. Nicht umsonst gibt es im .NET Framework auch die TryParse Methoden, die eben nicht schmeißen, sondern false zurückgeben, wenn die Input sich nicht parsen lässt. User-Input ist nämlich so eine Sache, bei der es öfters mal Probleme (DAU) gibt und da ist nicht immer eine Exception sinnvoll oder gar elegant.

Okay, ich bin von der Prämisse ausgegangen, dass wir von kritischen Teilen des Programmes reden. Dass User Input nicht mit Exceptions validiert wird, ist für mich selbstverständlich und deshalb habe ich vielleicht zu allgemein geantwortet.

Originally Posted by MrSm!th

p.s. Auch das Argument mit der Lesbarkeit hat 2 Seiten. Ein Nachteil von Exceptions ist nämlich auch, dass ein Ausführungspfad erstmal unsichtbar wird. Man sieht einer Anweisung nicht mehr unbedingt an, ob da etwas schiefgehen kann.

Wenn eine Funktion / Methode nicht mit nothrow definiert wurde, dann ist davon auszugehen, dass sie eine Exception werfen kann. Man sieht es den Anweisungen also durchaus an, ob sie schiefgehen kann oder nicht. Dem ersten Argument würde ich auch nur bedingt zustimmen. Denn wenn du Exceptions nur in kritischen Bereichen deines Programmes benutzt und dein Design durchdacht ist, dann wirst du einige wenige Punkte in deinem Programm haben, zu denen es zurückfällt, wenn eine Exception geworfen wird. Von denen wird es nicht viele geben und meistens wird dann so oder so das Programm terminiert. Du hast also nicht mehr überall Verzweigungen und wenn etwas fehlschlagen sollte, dann fällt dein Programm auf einen festen Punkt zurück. Das ist wesentlich lesbarer, als jeden Funktionsaufruf mit einem if zu versehen!
Wenn du jedoch so exzessiv Exception wirfst, wie man das z.B. in Java macht, dann wird es durchaus schnell unlesbar, das ist durchaus richtig.

Originally Posted by MrSm!th

p.p.s. Konstruierte Beispielprogramme sind immer so eine Sache. Ich kann nun auch ein Programm gezielt so schreiben, dass Exceptions schlechter dastehen. Macht nur wenig Sinn, weil beide Varianten ihre Daseinsberechtigung haben.

Das ist ein ganz einfach reduziertes Beispiel. Versuche es ruhig einmal selber äquivalenten, nicht trivialen Code mit und ohne Exceptions zu schreiben. Das Ergebnis wird dich verblüffen!

[MrSm!th]

Originally Posted by Nightblizard

Wenn eine Funktion / Methode nicht mit nothrow definiert wurde, dann ist davon auszugehen, dass sie eine Exception werfen kann.

Nicht in jeder Sprache gibt es so etwas (ungeachtet der Tatsache, dass wir hier im C++ Bereich sind). Aber genau da liegt auch das Problem: Grundsätzlich "kann" fast alles eine Exception schmeißen. Nur ob das wirklich in einem realistischen Szenario der Fall sein wird, ist eine andere Frage. In Sprachen wie Java, wo man zum catchen gezwungen wird, ist das dann entsprechend nervig.
Dennoch darf man das nicht aus den Augen verlieren, gerade bei Operationen auf persistenten Speicher. An einer Stelle eine potenzielle Exception (und damit eventuell die Notwendigkeit eines Rollbacks) vergessen und schon verursacht ein Fehler inkonsistente Daten.

Dem ersten Argument würde ich auch nur bedingt zustimmen. Denn wenn du Exceptions nur in kritischen Bereichen deines Programmes benutzt und dein Design durchdacht ist, dann wirst du einige wenige Punkte in deinem Programm haben, zu denen es zurückfällt, wenn eine Exception geworfen wird. Von denen wird es nicht viele geben und meistens wird dann so oder so das Programm terminiert.

Wenn man Exceptions richtig nutzt, eben als Ausnahmen, ja.
Ich bezog mich ja gerade auf die Überbenutzung von Exceptions, denn Mostey fragte ja, wieso man einen simplen Rückgabewert einer Exception vorziehen sollte. Was bei Überbenutzung von Exceptions herauskommt, sieht man am Müllhaufen namens Java.

Du hast also nicht mehr überall Verzweigungen und wenn etwas fehlschlagen sollte, dann fällt dein Programm auf einen festen Punkt zurück. Das ist wesentlich lesbarer, als jeden Funktionsaufruf mit einem if zu versehen!
Wenn du jedoch so exzessiv Exception wirfst, wie man das z.B. in Java macht, dann wird es durchaus schnell unlesbar, das ist durchaus richtig.

Das geht etwas an dem vorbei, worauf ich eigentlich hinaus wollte, aber das ist ebenfalls ein wichtiger Punkt, da hast du Recht. Schon alleine die Unterscheidung zwischen Runtime Exceptions und Compiletime Exceptions (und der Catchzwang für letztere) ist absolut lächerlich - Exceptions sind immer Ausnahmen zur Laufzeit. Naja, dass Java totaler Schrott ist, haben wir ja nun eh schon oft genug festgestellt.
Was ich eigentlich meinte ist aber tatsächlich, dass der Fehlerpfad verschwindet. Das ist gerade beim Testen und Ableiten von Äquivalenzklassen hinderlich, wenn du völlig übersiehst, dass an Stelle X Exception Y auftreten könnte. Und wenn das dann noch für "zu viel" verwendet wird (an Stellen, an denen ein Rückgabewert reichen würde), hast du schnell mal einen nicht unwahrscheinlichen Testfall, der aber auf den ersten Blick nicht auffällt.

Das ist ein ganz einfach reduziertes Beispiel. Versuche es ruhig einmal selber äquivalenten, nicht trivialen Code mit und ohne Exceptions zu schreiben. Das Ergebnis wird dich verblüffen!

Nicht wirklich, denn ich bin mir ja um die Eleganz von Exceptions bewusst ;O Allerdings ist das gerade bei trivialem Code so eine Sache. Exceptions und das Stack-Unwinding zeigen ja erst in großem Code ihre eigentliche Stärke (die von dir angesprochenen wegfallenden if-Ketten).

So wie ich das sehe, haben wir aber doch grundsätzlich eine ähnliche Ansicht über die Frage wann man Exceptions nutzen sollte und wann nicht. Dementsprechend würde ich vorschlagen, diese Grundsatzdiskussion dann nun auch aus diesem Thread herauszuhalten. Dem TE wird sie eh nicht all zu viel bringen.

[Mostey]

Originally Posted by MrSm!th

Situationsabhängig.
Wenn du mit C interagieren musst, hast du sowieso keine Wahl.

Ist ja wohl offensichtlich, oder? Wenn ich Exceptions nutzen kann, nutze ich sie. Und wenn nicht, dann ja wohl nicht.

Originally Posted by MrSm!th

Ich bezog mich ja gerade auf die Überbenutzung von Exceptions, denn Mostey fragte ja, wieso man einen simplen Rückgabewert einer Exception vorziehen sollte.

Nein, das habe ich so nicht gefragt. Es geht um Fehlermeldungen (die üblicherweise auch mehrere Gründe haben), nicht um simple Rückgabewerte. Wenn ich ne Funktion IsSunShining() habe, die mir ne Exception wirft wenn die Sonne nicht scheint, ist das überflüssig. Das wissen wir beide.

Habe ich jetzt aber versucht mich über HTTP mit einer Website zu verbinden und die Verbindung schlägt fehl, kann das an vielem liegen. Exceptions können das hier eingrenzen und das ist auf jeden Fall freundlicher, als alle möglichen Fehler über LastError abzufragen.

[LcPlayer1]

Originally Posted by Mostey

Nein, das habe ich so nicht gefragt. Es geht um Fehlermeldungen (die üblicherweise auch mehrere Gründe haben), nicht um simple Rückgabewerte. Wenn ich ne Funktion IsSunShining() habe, die mir ne Exception wirft wenn die Sonne nicht scheint, ist das überflüssig. Das wissen wir beide.

Habe ich jetzt aber versucht mich über HTTP mit einer Website zu verbinden und die Verbindung schlägt fehl, kann das an vielem liegen. Exceptions können das hier eingrenzen und das ist auf jeden Fall freundlicher, als alle möglichen Fehler über LastError abzufragen.

Es geht eben genau darum, dass es Fälle gibt, in denen ein Fehler auftritt, dieser aber nicht durch eine Exception, sondern durch einen boolean als Rückgabewert abgefangen wird.
So gibt es z.B. im Framework Qt eine Konvertierfunktion in QVariant, die ein true zurück gibt, wenn die Konvertierung erfolgreich war, andernfalls ein false.
Wir sprechen hier nicht von Funktionen, deren Grundfunktionalität in der Rückgabe eines booleans besteht, so wie in deiner genannten IsSunShining()-Funktion, sondern um booleans, die z.B. ein einfaches void ersetzen.

Mein Beispiel am Anfang des Threads war vielleicht etwas unglücklich gewählt, da hast du Recht.

[dowhile]

Was bei Überbenutzung von Exceptions herauskommt, sieht man am Müllhaufen namens Java.

Kannst du das vertiefen (Beispiele)?

[MrSm!th]

Wenn ich Exceptions nutzen kann, nutze ich sie

Nein, man nutzt sie eben nicht immer wenn man kann.
Man kann sie sogar als normalen Rückgabewert-Ersatz nutzen. Dass das Unsinn ist, erwähnst du ja etwas später selbst.

Originally Posted by Mostey

Nein, das habe ich so nicht gefragt. Es geht um Fehlermeldungen (die üblicherweise auch mehrere Gründe haben)

Nein, von Fehlermeldungen war nicht die Rede. Es ging um Fehler.

nicht um simple Rückgabewerte. Wenn ich ne Funktion IsSunShining() habe, die mir ne Exception wirft wenn die Sonne nicht scheint, ist das überflüssig. Das wissen wir beide.

Das meinte ich auch nicht. Es ging mir in der Tat um Fehler.
Als Beispiel seien die TryParse Methoden aus dem .NET Framework genannt.

Habe ich jetzt aber versucht mich über HTTP mit einer Website zu verbinden und die Verbindung schlägt fehl, kann das an vielem liegen. Exceptions können das hier eingrenzen und das ist auf jeden Fall freundlicher, als alle möglichen Fehler über LastError abzufragen.

Alle möglichen Fehler per catch abzufragen wäre genau das gleiche. Wenn die Fehler individuell behandelt werden müssen, ist das bei Exceptions nicht anders. Maximal kann einem da noch Polymorphie aushelfen. Wenn man hingegen sowieso jeden Fehler gleich behandelt (Messagebox mit "Fehler XY ist aufgetreten"), unterscheidet sich ein Fehlercode o.Ä. nicht von einer Exception, die nicht viel mehr Information enthält. Zumindest in der Behandlungsroutine und von der sprichst du ja.
Mag sein, dass Exceptions ein größeres Potenzial als Fehlercodes haben, allerdings zeigen deine Beispiele das kein bisschen. Schau dir am besten noch einmal Nightblizzards Posts an, die treffen den Nagel etwas besser auf den Kopf.
no offense

Kannst du das vertiefen (Beispiele)?

Nicht nötig, findest du an jeder Ecke.
Ich sehe grundsätzlich jede Compiletime-Exception als Schwachsinn an. Entweder hat sie das Potenzial eine Runtime-Exception zu sein oder sie ist einfach keine sinnvolle Exception.
Schau dir einen durchschnittlichen Java-Quellcode doch an. Quillt über an hunderten unnötigen try-catch Blöcken, die meist sowieso nur die Exception unterdrücken. DAS ist Überbenutzung und da kann ich jeden C-Fanatiker verstehen, der Objektorientierung und Exceptions skeptisch gegenüber steht, wenn sowas als DIE OO Sprache bezeichnet wird. Grauenhaft.

[Mostey]

Originally Posted by LcPlayer1

Es geht eben genau darum, dass es Fälle gibt, in denen ein Fehler auftritt, dieser aber nicht durch eine Exception, sondern durch einen boolean als Rückgabewert abgefangen wird.
So gibt es z.B. im Framework Qt eine Konvertierfunktion in QVariant, die ein true zurück gibt, wenn die Konvertierung erfolgreich war, andernfalls ein false.

Und wozu sollte man hier eine Exception nutzen? Du hast meine Sichtweise nicht ganz verstanden, ich sprach von Situationen bei denen es üblicherweise mehrere Gründe geben kann. Vielleicht war das nicht ganz ersichtlich von meinen Posts aber wiegesagt, wenn eine Konvertierung fehlschlägt (und das nur einen Grund haben kann, zum Beispiel bei Enum.Parse, nämlich das der String Wert zu keiner Enum Konstante passt) dann ist das mit einem bool doch völlig in Ordnung.

Daher auch die Argumentation vorher mit LastError, das brauche ich bei deinem Beispiel ja wohl auch nicht weil wir hier maximal 2 Codes hätten, Success und Failure.

Originally Posted by LcPlayer1

Wir sprechen hier nicht von Funktionen, deren Grundfunktionalität in der Rückgabe eines booleans besteht, so wie in deiner genannten IsSunShining()-Funktion, sondern um booleans, die z.B. ein einfaches void ersetzen.

Ich habe nie behauptet das man den bool als Rückgabewert abschaffen sollte. Das war auf (mehrdeutige) Fehlerfälle bezogen, nicht auf so einen Kleinkram.

Originally Posted by MrSm!th

Nein, man nutzt sie eben nicht immer wenn man kann.
Man kann sie sogar als normalen Rückgabewert-Ersatz nutzen. Dass das Unsinn ist, erwähnst du ja etwas später selbst.

Du bist mal wieder echt pingelig. Damit meinte ich, das man sie immer nutzen kann wenn man die Wahl zwischen LastError und Exception hat. Niemand sprach von einem kompletten Rückgabewert Ersatz.

Natürlich macht das jeder anders, das kannst du auch niemandem abschlagen.

Originally Posted by MrSm!th

Nein, von Fehlermeldungen war nicht die Rede. Es ging um Fehler.

Doch, es ist definitiv von beidem die Rede. Was macht denn LastError? Gibt dir den Fehler zurück. Was machst du mit dem Fehler? Du schlägst nach, was der Code zu bedeuten hat.

[MrSm!th]

Du redest ein wenig an der Essenz der Diskussion vorbei. Wenn du das weiter klären möchtest, schreib mir am besten eine PN.

[dasschild]

Originally Posted by MrSm!th

Du redest ein wenig an der Essenz der Diskussion vorbei. Wenn du das weiter klären möchtest, schreib mir am besten eine PN.

Stimme dir voll zu. Auch ist das Problem mit den wenigen Informationen zu dem Fehler durch 'std::error_code' eine sinnvolle Lösung. Exceptions sind einfach expensive und verhindern auch das sinnvolle strukturieren. Weiterhin werden auch asserts vorallem static asserts immer sinnvoller.

Wenn ich ne Exception schmeiße und dann wieder ganz wo anders im Programm bin und ich mir trotzdem sicher bin,dass die Funktion irgendwann funktionieren wird ist das vollkommen ok. Ein gutes Beispiel ist hierbei das Spinlock in C#,dass schmeißt ne Exception und dass heißt ich muss das mit wrappen wodruch wieder Overhead entsteht.

Zum Thread,die Frage ist weitgehend beantworten. Bool wird vorallem benutzt um die schlechte Gewohnheit von Exceptions auszutreiben und den vielleicht auch dazu anzuregen einen Wert wie überflüssig es auch erscheint doch zu checken.

@Mostey

Zu den ungenauen Error Codes von Win32 nochmal. Es gibt eine Funktion die heißt Format Message da kriegste die gleiche Message wie bei einer nativen Exception.