Fehlerbehandlung in einer Engine



  • Das ändert nichts daran, daß in _gutem_ C++-Code Exceptions analog zu C# oder Java verwendet werden.

    Jetzt bist du aber sehr wertend, indem du allen Code der auf Exceptions verzichtet wo sie nicht unbedingt nötig sind, als "nicht gut" bezeichnest.



  • knivil schrieb:

    Ein anderer Grund wie oben schon gesagt: In C++ sind Exceptions nicht fuers Resourcemanagement gedacht, sondern fuer echte Ausnahmen.

    Du hast Exception nicht verstanden.
    Lies dir bitte die Artikel durch - RAII alleine schreit ja schon nach "Exceptions sind perfekt für Resourcen Management".

    Nenne mir aber dennoch bitte einen Grund warum man nicht generell Exceptions verwenden sollte. Spezialfälle verlangen spezielle Maßnahmen aber im allgemeinen sind exceptions die beste Wahl.



  • Gut, hier meine Polemik: Du hast C++ nicht verstanden. RAII hat in erster Linie nichts mit Exceptions zu tun, es funktioniert auch wunderbar ohne Exceptions in C++ und wird bei mir staendig angewandt (ohne Exceptions, habe ich ja schon erwaehnt).

    Lies dir bitte die Artikel durch

    Mehr Polemik: Vielleicht haette der Autor sich mal Don’t Write Tutorials durchlesen sollen.



  • Na, komm, unter Unverständnis leiden wir doch alle hier. Ich habe Exceptions z.B. auch nicht verstanden. 🤡

    it0101@loggedoff schrieb:

    Jetzt bist du aber sehr wertend

    Ich habe nirgendwo behauptet, meine Äußerungen seien objektiv 😉

    it0101@loggedoff schrieb:

    indem du allen Code der auf Exceptions verzichtet wo sie nicht unbedingt nötig sind, als "nicht gut" bezeichnest.

    Das ist eine vorschnelle Implikation. Obgleich ich eine vernünftige Exception-Behandlung als Kriterium für guten Code sehe, anerkenne ich, daß Ausnahmen die Regel bestätigen.

    P.S.: Shade, du könntest auch mal die beiden meinerseits noch offenen Fragen andernorts beantworten, anstatt das Geflame hier fortzuführen 😉



  • Ich weiss, ich bin nen Idiot und hab keinen Plan, aber diesen Satz finde ich erschreckend:

    Immer dann, wenn ich sauber programmieren moechte.

    Was bitteschön haben Excpetions mit sauberem Code zu tun? Ich (und viele andere, u.a. auch einige "große" Bibliotheken), programmiere komplett ohne und meine Programme funktionieren trotzdem innerhalb der definierten Standardparameter. Ich finde die Aussage ein wenig übertrieben.
    rya.



  • knivil schrieb:

    Gut, hier meine Polemik: Du hast C++ nicht verstanden. RAII hat in erster Linie nichts mit Exceptions zu tun, es funktioniert auch wunderbar ohne Exceptions in C++ und wird bei mir staendig angewandt (ohne Exceptions, habe ich ja schon erwaehnt).

    Geil, und wie machst du die Fehlerbehandlung? Lass mich raten direkt nach deinem RAII Objekt steht dann

    result_type res = myobj.init();
    if( res == OK ) /* do something */
    else if( res == EPIC_FAIL ) /* do something else */
    else if( res == BIG_WTF ) /* do something entirely else */
    else /* yet another wtf */
    


  • Scorcher24 schrieb:

    Ich weiss, ich bin nen Idiot und hab keinen Plan, aber diesen Satz finde ich erschreckend:

    Immer dann, wenn ich sauber programmieren moechte.

    Was bitteschön haben Excpetions mit sauberem Code zu tun? Ich (und viele andere, u.a. auch einige "große" Bibliotheken), programmiere komplett ohne und meine Programme funktionieren trotzdem innerhalb der definierten Standardparameter. Ich finde die Aussage ein wenig übertrieben.
    rya.

    Wie lange gibt es diese großen Bibliotheken schon? Aha, merkst du etwas?



  • Bin dieser 100.000 mal geführten Diskussion zu müde. Deshalb habe ich dir Artikel geschrieben - da steht fast alles wichtige drin.

    Wenn ihr keine Exception nutzen wollt, dann bitte.



  • Um mal den Artikel zu zitieren:

    Ein C++-Programm ohne (oder mit fast keinem) Exception-Handling ist eine tickende Zeitbombe. Ein solches, in dem man vor lauter try's den Rest des Quellcodes nicht mehr erkennen kann ist aber auch nicht besser, da viele programminterne Fehler nicht einfach verschluckt werden dürfen, sondern behoben werden müssen (ein Programm, das nicht das tut, was es soll, dafür aber keine Fehler auswirft ist schlechter zu handhaben als ein solches, welches exakt das tut, was man von ihm erwartet, und dabei die eine oder andere MessageBox mit aussagekräftigen Fehlermeldungen bringt!)!

    Das war eigentlich das was ich sagen wollte: Wenn man Exceptions an jeder Ecke hat, bringt das NULL ( oder 0 ).



  • Scorcher24 schrieb:

    Ich weiss, ich bin nen Idiot und hab keinen Plan, aber diesen Satz finde ich erschreckend:

    Immer dann, wenn ich sauber programmieren moechte.

    Was bitteschön haben Excpetions mit sauberem Code zu tun?

    Siehst du das kleine Woertchen. Hier noch mal fuer dich: ich. Du bist derjenige, der verallgemeinert.

    Um mal den Artikel zu zitieren:

    Ich habe schon mal erwaehnt, dass die Artikel nicht besonders sind. Sie zeigen, wie man Exceptions einsetzt, aber nicht wann.



  • it0101@loggedoff schrieb:

    Um mal den Artikel zu zitieren:

    Ein C++-Programm ohne (oder mit fast keinem) Exception-Handling ist eine tickende Zeitbombe. Ein solches, in dem man vor lauter try's den Rest des Quellcodes nicht mehr erkennen kann ist aber auch nicht besser, da viele programminterne Fehler nicht einfach verschluckt werden dürfen, sondern behoben werden müssen (ein Programm, das nicht das tut, was es soll, dafür aber keine Fehler auswirft ist schlechter zu handhaben als ein solches, welches exakt das tut, was man von ihm erwartet, und dabei die eine oder andere MessageBox mit aussagekräftigen Fehlermeldungen bringt!)!

    Das war eigentlich das was ich sagen wollte: Wenn man Exceptions an jeder Ecke hat, bringt das NULL ( oder 0 ).

    Du hast die Aussage des Artikels wohl eher nicht verstanden. Da stand nichts von Exceptions, sondern von tries.



  • Also für mich gilt immer: Wenn die Software mit dem Benutzer in Kontakt kommt, dann sollte man sich mit Exceptions absichern, sonst reicht einfach ordentlich zu programmieren. Denn dafür sind Exceptions meiner Meinung nach gedacht. Um unerwartete Fehler abzufangen, aber nicht um die schlampige Arbeit des Programmieres zu verschleinern.


  • Administrator

    knivil schrieb:

    Exceptions sind in C++ fuer Ausnahmen und eine nicht vorhandene Datei ist keine Ausnahme, sondern vorhersehbar.

    1. Wie willst du das mit normalen C++ vorhersehen? 🙂
    2. http://www.cplusplus.com/reference/iostream/ios/exceptions.html
    Es wurde leider der Fehler gemacht, dass die Dinger nicht per Default gesetzt sind. Und inzwischen kann man wegen Rückwärtskompabilität dies nicht mehr reintun.

    knivil schrieb:

    So kann der Benuzter der Engine sich frei entscheiden, auf welcher Ebene er die Fehlerbehandlung machen möchte.

    Er hat nicht mehr die Freiheit, auf Exceptions zu verzichten. Andere Varianten der Fehlerbehandlung stehen nicht mehr zur Verfuegung.

    [] Du hast meinen Text vollständig gelesen und die Alternativen verstanden.

    knivil schrieb:

    Ein anderer Grund wie oben schon gesagt: In C++ sind Exceptions nicht fuers Resourcemanagement gedacht, sondern fuer echte Ausnahmen.

    Was verstehst du eigentlich unter "echte Ausnahmen"? Und wie vereinst du dies mit dem hier:
    http://www.cplusplus.com/reference/std/stdexcept/

    Übrigens das hier finde ich genial:

    knivil schrieb:

    Gut, hier meine Polemik: Du hast C++ nicht verstanden. RAII hat in erster Linie nichts mit Exceptions zu tun, es funktioniert auch wunderbar ohne Exceptions in C++ und wird bei mir staendig angewandt (ohne Exceptions, habe ich ja schon erwaehnt).

    Das ist korrekt! Und Shade Of Mine hat auch gar nichts anderes behauptet! RAII hat nichts mit Exceptions zu tun, aber RAII ist prefekt für die Nutzung von Exceptions.
    Meiner Meinung nach ist das der beste Beweis, dass du nicht mal verstanden hast, was Shade Of Mine gesagt hat.

    Grüssli



  • Scorcher24 schrieb:

    Was bitteschön haben Excpetions mit sauberem Code zu tun? Ich (und viele andere, u.a. auch einige "große" Bibliotheken), programmiere komplett ohne und meine Programme funktionieren trotzdem innerhalb der definierten Standardparameter.

    Zunächst ist es zweierlei, exceptionsicheren Code zu schreiben und Exceptions zu verwenden. Ersteres ist in C++ essentiell, da du in der Praxis oft Schnittstellen benutzt, die Exceptions werfen. Natürlich ist es zweifellos legitim, z.B. den Numbercrunching-Teil eines Programmes ohne Exceptionsicherheit in C oder Assembler zu schreiben und dabei Exceptions zu ignorieren - solange du sicher sein kannst, daß in diesem Code auch keine auftritt (etwa durch eine Callback-Funktion).

    Ob du nun Exceptions in deinen eigenen Schnittstellen benutzt oder nicht, ist eine andere Frage. Es gibt Situationen, die Fehlercodes anstelle von Exceptions erfordern, z.B. COM, aber selbst in COM ist das HRESULT-Idiom eigentlich nur ein Weg, Exceptions über Prozeß- und Modulgrenzen hinaus zu transportieren. Im Idealfall sieht ein COM-Interface daher so aus:

    struct [...] IMyInterface : public IUnknown
    {
        virtual HRESULT __stdcall _MyFunc (int Arg, float& __result) = 0;
        inline float MyFunc (int Arg)
        {
            int __result;
            throwExceptionIfNotSucceeded (_MyFunc (Arg, __result));
            return __result;
        }
    };
    
    struct MyClass : public IMyInterface
    {
        inline float MyFunc (int Arg)
        {
            // tatsächliche Implementation
        }
        virtual HRESULT __stdcall _MyFunc (int Arg, float& __result)
        {
            try
            {
                __result = MyFunc (Arg);
            }
            catch (std::exception& e)
            {
                // Exception-Informationen mittels SetErrorInfo() speichern
            }
            catch (...) // @Shade: Wenn dieser Anwendungsfall mal kein gutes
            {           // Beispiel ist, warum Exceptions immer von std::exception 
                        // abgeleitet sein sollten.
                return UNKNOWN_EXCEPTION_ERROR_CODE_BECAUSE_THERE_IS_NO_WAY_TO_GET_EXTENDED_EXCEPTION_INFORMATION;
            }
    };
    

    (Delphi kann diese Wrapper automatisch generieren, wenn man die safecall-Aufrufkonvention benutzt. .NET macht das AFAIK auch.)

    Wie das eine oder andere Beispiel im Verlaufe des Threads mittlerweile hinreichend demonstriert haben dürfte, führen Exceptions gewöhnlich zu deutlich saubererem Code.

    Edit 1, 3 und 4: Typographie 😡
    Edit 2: Lag.



  • RAII alleine schreit ja schon nach "Exceptions sind perfekt für Resourcen Management"

    Keine Ahnung wie es gemeint ist, aber RAII, Exceptions und Resourcen sind 3 unterschiedliche Sachen. RAII und Resourcen brauchen keine Exceptions, also warum diese beide Sachen jetzt ins Boot holen, um deren Vorteile auf Exceptions zu uebertragen? Das ist schummeln. Warum setzen dann die exceptionlastigen Sprachen wie Java und C# RAII nicht um (naja es geht, aber es ist trotzdem eine Krux).

    Du hast meinen Text vollständig gelesen und die Alternativen verstanden.

    Wenn du Exception-Handling meinst, dann ja. Gegenfrage: Findest du MyCalc(double ValueA, double ValueB) sei ein gutes Beispiel fuer den Einsatz von Exceptions?

    Echte Exceptions: z.B. out_of_memory. out_of_range ist irgendwie viel zu leicht verhinderbar. Entweder der Benutzer der Funktion testet, ob sein Wert im angegebenen Bereich liegt, oder in der Funktion selbst wird es getestet. Wo ist da der Vorteil? Nachteil: Wenn der Benutzer der Funktion aber genau weiss, dass sein Wert im Gueltigkeitsbereich liegt, ist der Test in der Funktion ueberfluessig.

    Aber ich merke schon: Knivil vs. Rest of the World ... 😞



  • knivil schrieb:

    Wenn du Exception-Handling meinst

    Ich meine eigentlich hauptsächlich meine beiden Artikel.



  • Du hast die Aussage des Artikels wohl eher nicht verstanden. Da stand nichts von Exceptions, sondern von tries.

    Wo geworfen wird, muss auch abgefangen werden 😉
    Ohne das Werfen von Exceptions spart man auch die try-catch-Geschichte.

    Aber so is das eben hier. Wenn man eine andere Meinung hat, dann macht sich auch keiner mehr die Mühe über Dinge nachzudenken, die man geschrieben hat.

    Is hier schon fast wie die "std::vector<T> in allen Fällen - was ist eigentlich new/delete"-Geschichte. Man gewöhnt sich an alles 😉



  • knivil schrieb:

    [...]Echte Exceptions: z.B. out_of_memory[...]

    Gerade die sind ein Paradebeispiel dafür, dass RAII und Exceptions perfekt harmonieren. RAII dreht das Potentiel erst mit Exceptions so richtig auf.



  • it0101@loggedoff schrieb:

    [...]Ohne das Werfen von Exceptions spart man auch die try-catch-Geschichte[...]

    Du verstehst die Aussage nicht. Das hast Du gerade wieder bestätigt. 🙂



  • Shade Of Mine schrieb:

    knivil schrieb:

    Wenn du Exception-Handling meinst

    Ich meine eigentlich hauptsächlich meine beiden Artikel.

    Ich habe jetzt zumindestens das Eingangsbeispiel zu gelesen (soll ja eigentlich arbeiten). Es gibt auch bessere Moeglichkeiten in C (abseits von errno). Schade, dass immer C herhalten muss, in C++ gibt es auch Mittel und Wege, auf Exceptions zu verzichten. Design by Contract (nicht C oder C++ spezifisch und sehr rudimentaer):

    // in is a valid input stream
    // out is a valid output stream
    // passwd is a non empty string
    encode( Stream in, Stream out, String passwd );
    

    Wie der Benutzer zu den gueltigen Streams kommt ist jetzt seine Sache.

    Ich habe gesehen, dass spaeter Design by Contract angerissen wird, aber was hat das mit Exceptions zu tun? (Ok, bei konsequenter Umsetzung braucht man ein assert nur fuers Debugging. But what's the point?)

    Tachyon schrieb:

    it0101@loggedoff schrieb:

    [...]Ohne das Werfen von Exceptions spart man auch die try-catch-Geschichte[...]

    Du verstehst die Aussage nicht. Das hast Du gerade wieder bestätigt. 🙂

    Ich verstehe it0101@loggedoff recht gut, siehe erster empfohlener Artikel von Davere.


Anmelden zum Antworten