Fehlerbehandlung in einer Engine

[Shade Of Mine]

knivil schrieb:

Habe mir die Anfaenge durchgelesen.

Musst schon alles lesen...

Es folgen nichtssagende oder schlechte Beispiele aus anderen Programmiersprachen fuer Fehlerbehandlung. Es wird auch nicht darauf eingegangen, das Exceptions in C++ andere Aufgaben wahrnehmen als z.B. in Java oder C#. Deswegen werden sie auch anders verwendet.

Weil exceptions in C++ und C# quasi identisch gehandhabt werden. Und die Unterschiede mit RAII werden auch genannt.

Eine Funktion kann auch mittels inout-Parameter Werte zurueckliefern etc. In C bekommt man mittels perror("...") dann zusaetzliche Information. Moeglichkeiten gibt es viele.

Steht alles in den Artikeln und auch warum das ein Käse ist.

Und nach der Lektuere wirst du wissen, dass Exceptions das richtige sind

Meistens nicht ... (meine Meinung)

Nenn mir einen guten Grund.

@Scorcher24:
lies die Artikel

[Dravere]

Für die interne Fehlerbehandlung in einer Engine, da kann man von mir aus Fehlercodes einsetzen. Es ist zwar teilweise ein wenig gefährlich, da man schnell einmal einen Fehler übersieht und dadurch noch mehr Fehler entstehen, vielleicht sogar fatale.
Sobald man aber aus der Engine raus einen Fehler zurückgibt, sollte man wenn möglich Exceptions verwenden. So kann der Benuzter der Engine sich frei entscheiden, auf welcher Ebene er die Fehlerbehandlung machen möchte. Sowas ist in meinen Augen für den Benutzer viel angenehmer zu handhaben.

Ich mag Fehlercodes bei eine Engine überhaupt nicht. Die stören immer meinen Programmfluss. Ich will meistens den Fehler nicht dort behandeln, wo er auftrat, sondern weiter vorne.
Wenn man trotzdem Fehlercodes anbieten möchte, dann schlage ich eine Überladung der Funktion vor, wo man eine Variable übergeben kann, wo dann der Fehlercode reingespeichert wird. Die Funktion hat dann eine nothrow Garantie.

Das nur als Zusatz für die Geschmacksfrage. Ansonsten verweise ich wirklich auf die Artikel und ein Überfliegen reicht nicht, um diese zu verstehen.

Grüssli

[Tippgeber]

Sehr interressant wie hier gegen Exceptions diskutiert wird von Leuten die von Exceptions nicht mehr als die Syntax kennen

[knivil]

Weil exceptions in C++ und C# quasi identisch gehandhabt werden.

Die Handhabung ist implemetationsspezifisch und steht nicht zur Debatte. Sie werden anders verwendet. Siehe Ressourcemanagement. Falls z.B. eine zu oeffnende Datei nicht existiert, dann wird 'ne Exception geworfen. In C++ nicht. Da es keine Ausnahme im eigentlichen Sinne ist. Exceptions sind in C++ fuer Ausnahmen und eine nicht vorhandene Datei ist keine Ausnahme, sondern vorhersehbar. Klar kann man in C++ das trotzdem so handhaben, aber es ist dann nicht mehr idiomatisches C++.

Steht alles in den Artikeln und auch warum das ein Käse ist.

Bin halt anderer Meinung (ohne gleich wertend zu sein). Es ist Kaese, weil die Beispiele so gewaehlt sind. Ich wuerde so nicht programmieren. Auch sehe ich z.B. in Artikel Exception-Handling fuer die Funktion MyCalc(double ValueA, double ValueB), dass das switch sich einfach im Werfen und Fangen der Exceptions verbirgt. Ein eher schlechtes Beispiel.

Nenn mir einen guten Grund.

Benutze ich Funktionen oder Klassen aus Bibliotheken (ob in Quell- oder Binaerform), so sind Exceptions stark restriktiv. Im Programmdesign muss ich dann auch Exceptions beruecksichtigen, obwohl das vielleicht garnicht noetig ist.

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.

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

[audacia]

knivil schrieb:

Falls z.B. eine zu oeffnende Datei nicht existiert, dann wird 'ne Exception geworfen. In C++ nicht. Da es keine Ausnahme im eigentlichen Sinne ist.

Nein, weil die File-Streams leider gravierende Mängel haben. Eine gut spezifizierte Klasse hat nie einen ungültigen Zustand (d.h. einen Zustand, in dem es illegal ist, eine ihrer Methoden aufzurufen). Bei den Datei-Streams reicht dafür der Aufruf der close()-Methode.

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

knivil schrieb:

Bin halt anderer Meinung (ohne gleich wertend zu sein).

Ach?

knivil schrieb:

Es folgen nichtssagende oder schlechte Beispiele aus anderen Programmiersprachen fuer Fehlerbehandlung.

knivil schrieb:

Benutze ich Funktionen oder Klassen aus Bibliotheken (ob in Quell- oder Binaerform), so sind Exceptions stark restriktiv. Im Programmdesign muss ich dann auch Exceptions beruecksichtigen, obwohl das vielleicht garnicht noetig ist.

Und in welcher Konstellation sollte das nicht nötig sein?

[knivil]

audacia schrieb:

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

Eben nicht. Guter C++ Code hat viel weniger try-catch als vergleichsweise C# und Java.

knivil schrieb:

Es folgen nichtssagende oder schlechte Beispiele aus anderen Programmiersprachen fuer Fehlerbehandlung.

Im Laufe der Zeit hat sich das Prinzip des Exception-Handlings (wörtl. aus dem Englischen übersetzt "Ausnahmebehandlung") durchgesetzt. Es basiert grob gesagt darauf, dass durch einen ungewöhnlichen oder nicht eingeplanten Zustand im Programm Exceptions ausgelöst werden, welche an einer zentralisierten Stelle abgefangen und behandelt werden kann. Es erwies sich als effizient einsetzbar, praktisch vorteilhaft und vor allen Dingen von den Methoden und Algorithmen des Programms gelöste Art der Fehlerbehandlung, wie sie beispielsweise die aus C bekannte Technik - bei welcher anhand des Rückgabewertes einer Funktion der Erfolg derselben geprüft wurde - nicht bot!

"im laufe der zeit ... es erwies sich ... praktisch ... vorteilhaft" - Ja, das ist nichts sagend. (Falls nicht, dann zeig mir doch mal die stichhaltigen Argumente in diesem Absatz)

Und in welcher Konstellation sollte das nicht nötig sein?

Immer dann, wenn ich sauber programmieren moechte.

Langsam hoert das Argumentieren auf und Suggestivfragen und Polemik ersetzen diese Diskussion. Schoen, dass du auch auf meine anderen Argumente eingehst.

[it0101@loggedoff]

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.

[Shade Of Mine]

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.

[knivil]

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.

[audacia]

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

[Scorcher24]

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.

[Hehe]

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 */

[Helferlein, Ein]

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?

[Shade Of Mine]

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.

[it0101@loggedoff]

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

[knivil]

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.

[Tachyon]

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.

[it0101@loggedoff]

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.

[Dravere]

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

[audacia]

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.