Habe folgende Situation:

template<class KeyType, class ValueType>
ValueType& DictionaryAsHashTable<KeyType, ValueType>::get()
{
	if(currentNode != NULL)
		return currentNode->value;
	else
		cerr << "Fehler: Eintrag nicht vorhanden!" << endl;
}

Im else-Fall kann kein Parameter zurückgegeben werden. Man darf es auch nicht.
Die Funktion darf auch nicht verändert werden.

In diesem Fall soll das Programm beendet werden. Welche einigermaßen saubere Lösung gibt es dafür?

Gruß heine

eine Exception mit throw werfen.

bis bald
akari

Trotzdem danke. Muss halt vorläufig mit 'ner Warnmeldung leben!

Exceptions haben wir noch nicht behandelt. Muss mir mal anschauen wie das geht.

Trotzdem danke. Muss halt vorläufig mit 'ner Warnmeldung leben!

Das ist nun garkeine gute Idee! Dann gib lieber einen Zeiger zurück und im Fehlerfall einen Nullzeiger.

Aber einfach ignorieren ist ganz bescheiden!

grüße

template<class KeyType, class ValueType>
ValueType& DictionaryAsHashTable<KeyType, ValueType>::get()
{
	static ValueType dummy; // notfalls noch entsprechend initialisieren
	if(currentNode != NULL)
		return currentNode->value;
	else
	{
		cerr << "Fehler: Eintrag nicht vorhanden!" << endl;
		return dummy;
	}
}

Später solltest du hier natürlich Exceptions verwenden.

Bis du dich in Exceptions eingearbeitet hast, kannst du auch erstmal einen Dummy zurückgeben.

template<class KeyType, class ValueType>
ValueType& DictionaryAsHashTable<KeyType, ValueType>::get()
{
	static ValueType dummy; // notfalls noch entsprechend initialisieren
	if(currentNode != NULL)
		return currentNode->value;
	else
	{
		cerr << "Fehler: Eintrag nicht vorhanden!" << endl;
		return dummy;
	}
}

Später solltest du hier natürlich Exceptions verwenden.

Und wie bekommt er mit das der Dummy garkein korrektes Objekt ist?

static ValueType dummy;

...

ValueType& MyFunc ()
{
    ...

    return dummy;
}

...

ValueType& result = MyFunc();
if(&result == &dummy)
    ...

Sollte imho funktionieren.

MfG SideWinder

grüße

Einfach nur nix tun und einen Defaultwert zurückzugeben ist so ziemlich Das Dümmste Was Man Tun Kann (tm).

Ahja, auf keinen Fall bitte exit(0) verwenden - der Returncode 0 wird eigentlich immer als "alles OK" angesehen, wenn schon exit dann exit(1) oder irgendwas bloss nicht 0.

Und wie bekommt er mit das der Dummy garkein korrektes Objekt ist?

Indem er eine Exception wirft. :p
Nicht so verbissen sehen, war ja nur als Übergangslösung gedacht. Und hat den Vorteil, dass wo jetzt kein Fehlerhandling gemacht werden kann, auch später kein Fehlerhandling stattfindet. Das Exceptionhandling erfogt separat von der eigentlichen Codesequenz.

David_pb schrieb:

Hm, gibts hier eine gewisse Abneigung gegen Zeiger?

Ja, gibt es.

heine789 schrieb:

Die Funktion darf auch nicht verändert werden.

Im else-Fall kann kein Parameter zurückgegeben werden. Man darf es auch nicht.
Die Funktion darf auch nicht verändert werden.

In diesem Fall soll das Programm beendet werden. Welche einigermaßen saubere Lösung gibt es dafür?

Die Vorgabe ist doch ganz klar, oder? Ich sehe zumindest keine Möglichkeit wie da Exceptions oder Dummy-Werte helfen sollen.

Die IMHO einzig richtige Antwort heisst im übrigen nicht wie ich zuerst fälschlicherweise geschrieben habe abort() sondern -> terminate() <-. Man verzeihe mir den Patzer

terminate() tut zwar normalerweise auch nixe ausser abort() aufzurufen, aber man kann den terminate-handler auf eine eigenen Funktion verbiegen, und die Möglichkeit wollen wir dem Programm ja nicht nehmen.

Nö, Exceptions sind hier immer noch die saubere Lösung.

Nenne mir bitte die Begründung warum deiner Meinung nach hier das Werfen einer Exception angebracht wäre, dann kann ich dir sagen wo du den Denkfehler machst.

BTW: wenn du eine Exception wirfst und nirgends fängst werden auch keine Destruktoren mehr abgearbeitet. Was auch gut so ist.

Die Funktion darf auch nicht verändert werden.

dann ruf diese funktion nur von einer anderen auf, die vorher 'currentnode' checkt. allein davon ist's ja abhängig ob's klappt oder nicht ...

Zudem kann es durchaus sein das Klassen anderer Bibliotheken darauf angewiesen sind das ein Destruktor aufgerufen wird. Lockfiles werden wohl nicht gelöscht, fremde Tasks die man fernsteuert nicht geschlossen.

Mit werfen der Exception gebe ich so dem Anwender der Klasse/Funktion die Möglichkeit zu reagieren. Mit einem exit lasse ich einfach Möglichkeiten weg das Problem sauber zu lösen und riskiere das unbekannte Resourcen nicht aufgeräumt werden.

Nenne mir bitte die Begründung warum deiner Meinung nach hier das Werfen einer Exception angebracht wäre, dann kann ich dir sagen wo du den Denkfehler machst.

Vielleicht ist ne Datei geöffnet? Vielleicht steht schon was im Buffer? Vielleicht geht deine config-Datei flöten?[/quote]

Nu zu dem Grund warum ich meine dass es in Fällen wo man eine Precondition verletzt sieht schlauer ist das Programm einfach abzubrechen, und zwar ohne Stack-Unwinding. Einfache Antwort: eben genau weil dann kein Stack-Unwinding mehr passiert, also keine Destruktoren mehr laufen.
Destruktoren auszuführen hat nur dann einen Sinn wenn man davon ausgeht dass das Programm noch in einem gültigen Zustand ist. Da aber eine Precondition verletzt wurde heisst das es liegt ein Programmierfehler vor. Wo dieser Fehler genau liegt können wir nicht wissen, der kann direkt in der aufrufenden Funktion liegen, oder in einem ganz anderen Modul. Demzufolge können wir auch nicht wissen was dieser Fehler noch angerichtet hat - d.h. wir können nichtmehr garantieren dass das Programm noch in einem gültigen Zustand ist. In der Situation das Programm noch irgendwie fortzusetzen (und Destruktoren ausführen hiesse das Programm fortsetzen) kommt einem Pokerspiel gleich.

Daher macht es IMHO mehr Sinn das Programm einfach abzubrechen.

Der Denkfehler liegt also IMHO darin anzunehmen es sei sicher noch irgendwelchen Code auzuführen wenn ein unbekannter Fehler dazu geführt hat dass ein Ereignis eingetreten ist welches per definitionem nie eintreten darf.

Wo ist bei der Schlussfolgerung der Denkfehler ?

Wäre die Schlussfolgerung dann nicht, das Exceptions völlig überflüssig sind und es generell besser wäre terminate zu verwenden ?

nö, exceptions sind schon gut, jedenfalls wenn man sofort drauf reagiert. kommt das 'catch' zu weit oben kann man u.u. den schaden nicht mehr begrenzen und muss dann das programm beenden um schlimmeres zu vermeiden...

Ich würde mich freuen, wenn Plotzenhotz sich hierzu noch mal äußern könnte, da man gerade bei gegensätlichen Meinungen oft viel lernen kann.

...Weiters sollte man wissen dass das Stack-Unwinding nur dann passiert wenn die Exception auch irgendwo gefangen wird....

Das höre ich zum ersten Mal !!! Glaube es auch und habe es gerade ausprobiert (gcc 3.4.4).

GUUUT zu wissen - und seltsam, daß es mit bislang in meinem der "Expertbücher" begegnet ist. Außerdem schwer abgefahren: Ich dachte immer, Stackunwinding sei Bestandteil ein fertig compilierten Moduls. Anscheinend stellt ein Modul aber nur "Informationen" zur Verfügung, mit denen das gelinkte Modul das dann durchführen kann...
Ich muß mir da noch ein paar Gedanken drüber machen ...

Einerseits finde ich Deine Ausführungen recht logisch (aus individueller Entwicklersicht), andererseits aber auch (aus "Gesamtsystemsicht") für zu kurz gesprungen.
- Wenn der Programmzustand "vermurkst" ist .... was könnte ein ausgeführter Dtor daran noch verschlimmern ?
- in Serversystemen wirst Du massiv Ärger bekommen, wenn ein falscher Parameter (wenn man ehrlich ist: Welches größere Programm ist wirklich fehlerfrei ?) zu einem kompletten Abbruch/Restart führt.
- terminate() ist ein absolutes "no go" für Systeme, die eine retry-Strategie unterstützen sollen.
...

*grübel*

Gruß,

Simon2.