Exception oder Signal für Fehlerausgabe?

[Massimo B.]

Hallo.

Auf für einfache Fehlermeldungen habe ich bisher gerne Exceptions verwendet:

Code: Alles auswählen

if (size==0) {
	throw QString( "No layout found!" );
}

//...
try{
//...
}
catch (QString& errmsg) {
	QMessageBox::warning(this, tr( "File error" ), errmsg);
}

Nun bietet aber Qt für den Informationstransport Signals/Slots. Ist das eher zu empfehlen?

[upsala]

Meine Erfahrung ist, daß Exceptions in den meisten Projekten nicht verwendet wird, weil es die Leute einfach nicht können (mich eingeschlossen). Aber ich denke es spricht nichts dagegen sie zu verwenden. Wenn ich mich nicht täusche kann man damit mehr Fehler auch einfacher abfragen, als wenn man es per Hand machen muß, oder?

[Volker]

Problem bei Exceptions ist IMHO häufig die Speicherverwaltung. Man muss aufpassen keine Speicherlöcher zu verursachen wenn eine Exception geworfen wurde.

[Christian81]

Ausserdem gibt es Probleme wenn exceptions über sharedLib-Grenzen gehen.

[Massimo B.]

Ich habe nun die besagten Exception Konstruktionen umgebaut.
Bisher wurde eine Memberfunktion mit try{a->doThis()} ausgeführt und gleich danach der QString mit catch aufgefangen. Das Programm wurde dadurch sehr unübersichtlich.
Nun habe ich meist einen bool Rückgabewert, um zu testen, ob die Funktion erfolgreich war (ohne weitere Informationen) udn außerdem ein Signal newMessage(const QString&). Das Signal ist direkt mit einem Slot verknüpft, der einen Warning Dialog generiert. Das Programm ist nun besser zu lesen.
Ich wollte nur anfangs gerne das volle Potential von C++ ausschöpfen.

Nebenbei: Für Klassen, die Qt-frei gehalten werden sollen, verwende ich ein Watcher-Objekt. Die freie Klasse hält einen Pointer auf das Watcher-Objekt, welches selbst Qt-Signale sendet.