Fehlerbehandlung in der Praxis - Errorcode, Exception, was besseres?

sofa schrieb:

Wenn man es so macht, besteht aber wieder das Problem, das jede GUI das machen muss, wenn man sie austauschen will oder mehrere hat.

Das ist aber genau das was du willst, denn je nach GUI ist die Eingabemaske völlig anders strukturiert, evt. sogar das Eingabeformat und dementsprechend weiß nur der Code der die GUI-Logik enthält und die GUI aufbaut wie er die Daten richtig und sinnvoll validieren kann.

Sollte das nicht notwendig sein, dann kann man den Code zur Validierung auslagern, so dass alle Oberflächen ihn gemeinsam nutzen können, es sagt doch niemand, dass du den Code mehrfach schreiben musst, nur weil du vor Ort prüfst.

Wiss0r schrieb:

Sollte das nicht notwendig sein, dann kann man den Code zur Validierung auslagern, so dass alle Oberflächen ihn gemeinsam nutzen können, es sagt doch niemand, dass du den Code mehrfach schreiben musst, nur weil du vor Ort prüfst.

Und was macht die Validierung im Fehlerfall, Exception oder Errorcode? Darum gehts.

sofa schrieb:

Wiss0r schrieb:

Sollte das nicht notwendig sein, dann kann man den Code zur Validierung auslagern, so dass alle Oberflächen ihn gemeinsam nutzen können, es sagt doch niemand, dass du den Code mehrfach schreiben musst, nur weil du vor Ort prüfst.

Und was macht die Validierung im Fehlerfall, Exception oder Errorcode? Darum gehts.

Die Validierung weiß was schief gelaufen ist, da es sich um Benutzereingaben handelt in otzes Posting, sollte sie eine Fehlerbeschreibung in textueller Form zur Verfügung stellen und einfach über einen booleschen Rückagetyp signalisieren, dass die Daten nicht erfolgreich validiert werden konnten.

Beim Einlesen von Dateien kommt es darauf an, wenn wichtige Dateien der Anwendung korrupt sind, dann ist es durchaus in Ordnung sich mit einer Exception zu verabschieden. Kommt die Datei vom Benutzer sollte er möglichst genau darüber informiert werden was schief gelaufen ist (natürlich so dass er versteht was gewollt ist).

ghorst

im falle einer gui steht dir noch ein dritte weg offen: messages.
will heißen, du stellt den fehler fest und statt ihn versuchen vorort zu erledigen, erzeugst du eine message, dass etwas schiefgegangen ist. dann muss die nur noch jemand fangen. hier mal am bsp von qt mit signal-slot und dem validieren eines eingabetextes (value). die variable msg hängt dann vom validator ab. also bswp "Not a number." oder ähnliches:

...
int pos;
if (validator.validate(value,pos)==QValidator::Invalid)
{
	emit(validationFailedSignal(msg,value,pos));
}
...
[irgendwo der validationFailedSlot als bsp hier eine msgbox]
void validationFailedSlot(QString msg,QString value, int error_pos)
{
	QMessageBox::warning(parent, tr("Validation Error"), QString(tr("%1\nIn "%2" at Position: %3")).arg(msg).arg(value).arg(error_pos));
}

andere varianten als die messagebox sind auch denkbar. man könnte bspw eine fix probieren, den wert zurückzusetzen oder sonst etwas machen. der vorteil an der message ist, dass man die fehlerbehandlung von der eigentlichen fehlererkennung trennen kann und so beides einfacher recyclen kann.

Bashar schrieb:

loks, du bist komplett auf dem Holzweg,

Sagt der der das Prinzip eines BEISPIELS nicht begriffen hat. Damit zeigt sich nur wieder as hier ernstgemeinte Diskussion unmöglich ist.

Bashar

loks schrieb:

Sagt der der das Prinzip eines BEISPIELS nicht begriffen hat. Damit zeigt sich nur wieder as hier ernstgemeinte Diskussion unmöglich ist.

Wenn man keine Ahnung hat aber auch nicht :p

otze

@Bashar

Alles was in irgendeiner Weise von Benutzereingaben abhängt ist sicher ein erwarteter Fehler (Syntaxfehler in der Eingabe, angegebene Datei existiert nicht usw.). Aber wann Exceptions?

Exceptions würde ich werfen, wenn ein Fehler auftritt, der eigentlich nicht auftreten sollte, und bei dem ich den geordneten Programmablauf nicht mehr garantieren kann. Zum Beispiel wenn sich die Hardware weigert das zu tun was man will, oder wenn aufeinmal die verbindung zu einem Server weg ist.

Anderes Beispiel können parser sein. Wenn irgendwo tief unten im parser callstack ein Fehler passiert, ist es einfacher mit einer exception rauszuspringen, und dann auf oberster Ebene zu fangen. Also sowas:

bool parseData(string data)
{
    try
    {
        doParse(data);
        return true;
    }
    catch(ParseException& e)
    {
         cerr<<e.message;
         return false;
    }
}

Das macht den Parser selbst direkt viel schöner, weil sich höherlevelige funktionen nicht um den status der unteren zu kümmern brauchen. Sie könnten wahrscheinlich eh nicht sonderlich viel daran ändern.

otze schrieb:

@Bashar

Alles was in irgendeiner Weise von Benutzereingaben abhängt ist sicher ein erwarteter Fehler (Syntaxfehler in der Eingabe, angegebene Datei existiert nicht usw.). Aber wann Exceptions?

Exceptions würde ich werfen, wenn ein Fehler auftritt, der eigentlich nicht auftreten sollte, und bei dem ich den geordneten Programmablauf nicht mehr garantieren kann. Zum Beispiel wenn sich die Hardware weigert das zu tun was man will, oder wenn aufeinmal die verbindung zu einem Server weg ist.

Anderes Beispiel können parser sein. Wenn irgendwo tief unten im parser callstack ein Fehler passiert, ist es einfacher mit einer exception rauszuspringen, und dann auf oberster Ebene zu fangen. Also sowas:
bool parseData(string data)
{
    try
    {
        doParse(data);
        return true;
    }
    catch(ParseException& e)
    {
         cerr<<e.message;
         return false;
    }
}
Das macht den Parser selbst direkt viel schöner, weil sich höherlevelige funktionen nicht um den status der unteren zu kümmern brauchen. Sie könnten wahrscheinlich eh nicht sonderlich viel daran ändern.

Das sind meist genau die Fälle wo man in C goto benutzen muss(te) und hier finde ich sind Exceptions auch der einzig sinnvolle Weg, da alles aufgeräumt wird (wenn man sauber gearbeitet hat) und die entsprechende Methode sofort verlassen wird.

Was ich auch einen unschätzbaren Vorteil an Exceptions finde: man kann die programmtechnische Identifikation des Fehlers und die textuelle für den Benutzer koppeln. In C sieht es ja meist so aus, dass man eine Fehlernummer zurückgibt und diese dann erst mühsam übersetzen muss.

DEvent

Ich finde ein wesentlicher Vorteil von Exceptions sind, dass sie im unguenstigsten Fall das Programm einfach beenden. Wenn man einen Fehlercode ignoriert, dann laeuft das Programm weiter im undefinierten Zustand und das ist das Schlimmste was passieren kann.

Gibt es aber noch andere Techniken ausser Exceptions und Fehlercode fuer die Fehlerbehandlung?

Bashar

DEvent schrieb:

Gibt es aber noch andere Techniken ausser Exceptions und Fehlercode fuer die Fehlerbehandlung?

Fehlercallbacks, sowas wie new_handler o.ä. Das kann man vielleicht einsetzen, wenn Exceptions nicht zur Verfügung stehen, wenn man auf C als gemeinsamen Nenner zurückgreifen muss.

Common Lisp Conditions. Von der Idee her sowas wie Exceptions, aber irgendwie auch nicht, weil der Handler vor dem Stack-Unwinding eingreifen kann.