try-catch Konzeptfrage

Fake oder Echt

Wie der Titel schon sagt, habe ich ein paar Fragen zur Ausnahmebehandlung via try-catch.
Im Prinzip wirft man Fehlermeldungen mit Typen, z.B.

#include <iostream>
using namespace std;

void Test (int iThrowError)
{
    throw iThrowError; //int werfen
}

int main ()
{
    try {
        Test (23);
    }
    catch (int e)
    {
        cout << "Fehler: Integer (" << e << ")";
    }
    catch (...)
    {
        cout << "Fehler: Anderer";
    }

    return 0;
}

Soweit so gut. Aber ich verstehe nicht, wie das mit Exception-Klassen funktionieren soll. Wenn ich eine Klasse Exception erstelle und die dann werfen lasse, wie arbeite ich dann mit der Klasse bzw. was kommt dann alles in die Klasse zur Fehlerbehandlung rein? Ich habe schon einige Beschreibungen und Tutorials gelesen, aber sehe in dem Punkt einfach nicht durch, wie das gedacht ist. Ich hoffe mir kann das jemand erklären bzw. ein gutes Beispiel zeigen.

Weils so viel besser ist:

try {
    evil();
} catch(MeineSQLException& err) {
    cout << err.getErrorNum() << ...
    cout << "Hasu du depp auch den Dienst angeschalten?";
} catch(std::exception& err) {
    cout << err.what();
}

Fake oder Echt

Ja ok, dass das besser ist, habe ich schon verstanden bloß wenn ich mir einfach eine Fehler-Klasse erstelle und wunderschöne Methoden zur Fehlerbehandlung erstelle, hab ich ja dann nicht so viel davon, wenn ich die Klasse nicht richtig benutzen kann, weil benötigte Daten fehlen. Oder werden die Daten dann dem Konstruktor übergeben? Wenn ja, dann müsste mann wieder für fast jede Möglichkeit einen Konstruktor anlegen, also überladen.

Nö es sollte reichen für jede Art von Aussnahmen eine Klasse zu basteln, diese von std::exception ableiten und what() überschreiben.

Fake oder Echt

'Tschuldige wenn ich so dumm frage: ist das ernst gemeint?

Artchi

Wieso sollte es kein ernst sein?
Ob du das machst, ist deine (Design-)Entscheidung. Du kannst natürlich auch die Standard-Exception-Typen verwenden. Kannst aber auch von diesen ableiten. Kannst auch von keiner Exception ableiten und nur einen int-Wert werfen. Ist deine Entscheidung. Obs schön ist, ist ne andere Frage.

Es ist sinnvoll, z.B. bei einer SQL-Library z.B. ein paar Exception-Typen zu haben, die was mit SQL zu tun haben. So kann der SQL-Library-Benutzer fein granularer seine catch-Blöcke bauen. Wenn alle nur std::exception werfen, kann man schlecht als User eine Entscheidung treffen, was man abfangen will. Vielleicht will man sich ja nur um SQL-Exceptions kümmern und alle anderen Exceptions interessieren einen nicht? Also wird man viele Exception-Typen anbieten müssen. Wieviel, ist eine Entscheidung...

Fake oder Echt

Artchi schrieb:

Wieso sollte es kein ernst sein?

Sry, dass ich nochmal gefragt habe. Ich beschäftige mich noch nicht so lange mit Exceptions und da hört sich ein "Leite nur aus einer Klasse ab und überlade immer nur Methode x" eben ein bisschen komisch an

Artchi schrieb:

Es ist sinnvoll, z.B. bei einer SQL-Library z.B. ein paar Exception-Typen zu haben, die was mit SQL zu tun haben. So kann der SQL-Library-Benutzer fein granularer seine catch-Blöcke bauen. Wenn alle nur std::exception werfen, kann man schlecht als User eine Entscheidung treffen, was man abfangen will. Vielleicht will man sich ja nur um SQL-Exceptions kümmern und alle anderen Exceptions interessieren einen nicht? Also wird man viele Exception-Typen anbieten müssen. Wieviel, ist eine Entscheidung...

D.h. für jeden "wichtigen" (in Anführungszeichen, da relativ) Fehler sollte man eine eigene Klasse einrichten, die dann als Exception-Handler dient um den User möglichst viel Spielraum in Sachen Ausnahmebehandlung zu lassen. Wenn ich das jetzt so richtig verstanden habe, dann wäre meine Frage zum Konzept ja nun geklärt. Also danke an euch beide

Ja.

Entschuldige die dumme Antwort (Ja), da hab ich die vorherigen 2 Posts nicht gesehen.

Nochmal, auch wenn du wohl das richtige meinst: Nicht für jeden wichtigen Fehler, sondern für jeden wichtigen FehlerTYP.

Fake oder Echt

Ja ok dann wär das jetzt geklärt, den kleinen Unterschied zwischen Fehler und Fehlertyp merk ich mir jetzt noch und dann wär das komplett, danke