Eigen Exceptionklasse!Wie und was??

Hmm hallo leute,

meine fragen:

1: wie erstelle ich richtig eine eigene exceptionklasse?
d.h wann mach ich sie komplett selber und wann leite ich ab?

wie ist eine eigene klasse aufgebaut? oder wie sollte sie es sein?
vielleicht kann mir da jemand mal ein schönes beispiel oder tolles tutorial geben?

2: was sollte in so eine klasse alles rein, oder was soll sie eigentlich machen? Nur ne fehlermeldung anzeigen? fehler bearbeiten? Wenn ja, wie?

Sorry wegen den vielen fragen, aber ich wollte eben grad eigene exceptions machen, habe bei der überlegung aber gemerkt, das ich keinen richtigen anfang und kein richtiges system finde!

Meine Meinung:

Immer von std::exception ableiten, dann kann man immer noch mit what() den Fehler anzeigen wenn der Caller nicht weiß was für eine genaue Exception geworfen wird.

Inhalt der Klasse: Alles was dein Fehler beschreibt (also z.B: SQL Query das nicht geklappt hat, der Fehler des SQL-Servers und die Fehlernummer)

Simon2

Hi,

das ist ein ganz einfaches Thema: Du kannst ALLES werfen ! (z.B. throw "Simon2"; )
Ich selbst leite meine Exceptionklassen von std::exception ab, aber das braucht's nicht und es gibt auch gute Gründe dagegen.

Und: Das ist ein ganz schweres Thema !
Leider habe ich noch kein einheitliches "AllForOne"-Konzept zum Thema Fehlerbehandlung gefunden. Es gibt verschiedene Techniken, die einem zur Verfügung stehen und aus denen man sich das jeweils geeignete zusammenbasteln muß.
Ein wichtiger Aspekt dabei ist IMO: Was kann der "Exception-Fänger" machen ?
Und zwei wichtige Techniken sind Vererbung und Fehlermeldungen.

So kannst Du einerseits für jede fachliche Fehlersituation eine eigene Klasse definieren und die evtl. von entsprechenden "Bündelungsexceptions" ableiten (z.B. eine Exception "Parameterfehler" und davon ableitet "ParameterTooBig", ParameterTooSmall", "ParameterNULL", ...) Vorteil: Der Fänger kann relativ einfach technisch "fachlich korrigieren" (veschiedene catch-Clauses); Nachteile: Es kommt ziemlich schnell ein Riesenwust von exceptionklassen, die teilweise nicht mehr eindeutig gegeneinander abzugrenzen sind.

Außerdem/Stattdessen kannst Du Deine Exceptionklasse mit einem Fehlermeldungstext ausstatten (solltest Du sogar, wenn Du von std::exception erben möchtest). Vorteil: Weniger Exceptionklassen + einfacher auswertbar für "das menschliche Auge"; Nachteil: maschinell nicht gut auswertbar.

Innerhalb der Exceptionklasse würde ich keine "Ablauflogik" einbauen; die passt doch in immer mehr Fällen nicht mehr. Sie sollte lediglich Informationen über die Ausnahmesituation beinhalten, aber nicht selbst aktiv werden.

Da Du eher am Anfang zu stehen scheinst, würde ich Dir raten, mit beiden Techniken ein wenig rumzuspielen.

Gruß,

Simon2.

Artchi

Außerdem/Stattdessen kannst Du Deine Exceptionklasse mit einem Fehlermeldungstext ausstatten (solltest Du sogar, wenn Du von std::exception erben möchtest). Vorteil: Weniger Exceptionklassen + einfacher auswertbar für "das menschliche Auge"; Nachteil: maschinell nicht gut auswertbar.

Was meinst du mit maschinell nicht gut auswertbar? Das std::exception zu allgemein ist? Ja, das stimmt. Es gibt aber auch Spezialisierungen von exception:
http://www.kharchi.de/cppratgeber3.htm#3.3_Standard_Exceptions

Wenn jemand z.B. an eine Funktion einen ungültigen Parameter übergibt, kann ich std::invalid_argument werfen, muß nicht ein einfaches exception sein. Wenn ein Wert zu groß oder klein ist, werfe ich std::out_of_range. Ich kann aber auch von invalid_argument ableiten und daraus ein invalid_kekse_argument machen.

@asdaskd! Bei einer eigenen Exception-Klasse muß man aufpassen, das diese z.B. nicht selber eine Exception erzeugt. Kann einen Teufelskreis ergeben.

Ich selber versuche meistens die bereits existierenden Klassen zu nutzen, und wenn es doch mal eine eigene sein soll, leite ich von einer der Std-Exceptions ab. Das tue ich um eine spezielle "Aussage" treffen zu können. Z.B. macht es Sinn, in einer Netzwerk-Lib eine connection_failed-Exception zu haben. Die würde ich dann einfach von einer Std-Exception ableiten.

tntnet

Simon2 schrieb:

Ich selbst leite meine Exceptionklassen von std::exception ab, aber das braucht's nicht und es gibt auch gute Gründe dagegen.

Ich bin der Meinung, daß Exceptions immer direkt oder indirekt von std::exception abgeleitet werden sollten. Die Klasse std::runtime_error ist sehr gut geeignet, u.a. da sie leichter ableitbar ist, als std::exception direkt.

Welche guten Gründe gibt es denn, es nicht so zu tun?

Simon2

Artchi schrieb:

Außerdem/Stattdessen kannst Du Deine Exceptionklasse mit einem Fehlermeldungstext ausstatten (solltest Du sogar, wenn Du von std::exception erben möchtest). Vorteil: Weniger Exceptionklassen + einfacher auswertbar für "das menschliche Auge"; Nachteil: maschinell nicht gut auswertbar.

Was meinst du mit maschinell nicht gut auswertbar? ...

Wenn man nur eine Exceptionklasse definiert, die im Wesentlichen "Fließtext" anbietet, kann man das nur schwer im catch (oder nachgelagerten Funktionen) auswerten. Ich sage das nur, weil ich Derartiges leider zu oft gesehen habe ("if(e.what()[3] == "g") { ...." & Co ). Dafür kann man in Fließtext wiederum gut etwas unterbringen, was einem "menschlichen Auswerter" weiterhilft.

Zu "Maschinell auswertbar" eignet sich genau das besser:

Artchi schrieb:

...
...Wenn jemand z.B. an eine Funktion einen ungültigen Parameter übergibt, kann ich std::invalid_argument werfen ... std::out_of_range., ...invalid_kekse_argument machen....

Mir geht es nur darum, dass man sich dieses Unterschiedes bewusst ist.

Gruß,

Simon2.

Simon2

tntnet schrieb:

...Welche guten Gründe gibt es denn, es nicht so zu tun?

Habe ich mir nicht gemerkt, weil ich letztlich auch die Ableitung von std::exception die bessere Lösung fand, aber ich weiß, dass ich mal was dazu gelesen habe und dachte "gar nicht so dumm !".
Mit dieser Floskel wollte ich mich nur gegen "Besserwisser" (echte und selbsternannte) absichern und klarmachen, dass ich meine Meinung nicht für sakrosankt halte.

Gruß,

Simon2.

ok, die meinungen an sich habe ich verstanden!
scheint mir auch logisch!

hat jemand viell eine gute seite, wo es praktisch veranschaulicht wird?

ableiten einer eigenen klasse von exception?
eigene fehlerklasse die nicht abgeleitet ist!

richtiger einsatz dieser klassen?

oder kann mir jemand dazu ein beispiel schreiben?

direkt am anfang stehe ich nicht, allerdings habe ich mich mit dem theme der eigenen exception-klassen so noch nicht beschäftigt!

auch bietet mir google da immer nur einen kleinen teil an informationen, ich hätte aber gern ein einfaches aber relativ vollständiges beispiel, welches mir dein einsatz erklärt!

MartinMilbret

Man kann auch eine eigene Exceptionklasse schreiben
Das ist nicht mal so schwer
Hier ist ein Beispiel das ich für C++ und meine Engine(2D/3D) nutze

Deklaration:

class CException
{
 public:

 CException();
 CException(std::string);
 virtual ~CException();

 virtual void SetError(std::string);
 virtual std::string GetError();
};

Implementation:

#include "Exception.h"

CException::CException()
{
 m_StrError="";
}

CException::CException(std::string Error)
{
 m_StrError=Error;
}

CException::~CException()
{
}

void CException::SetError(std::string Error)
{
 m_StrError=Error;
}

std::string CException::GetError()
{
 return m_StrError;
}

Einfach oder?
Aber wenn man es sehr genau haben will, dann sollte man von std::exception und deren Klassen nutzen
Aber für allgemeine Sachen kann man auch das nutzen

Artchi

Hem, wenn du von einer Std-Exception ableitest, ist das ganz einfach:
http://www.kharchi.de/cppratgeber3.htm#3.4_Eigene_Exceptions

Kannst auch noch einen Standard-Konstruktor anbieten, aber meistens will man ja doch einen Begründungstext dazu geben.

Eigene Exceptions sind so zu schreiben, wie du es willst. Gaaaanz einfach ist sowas:

class meine_exception
{
};

Reicht schon zum werfen.

Ein Grund nicht von std::exception ableiten zu sollen ist vielleicht das es keinen Unicode Support hat.