STL vector "at" und try and catch error

Frodus

Hi Leute,

kann mir vielleicht jemand sagen wo hier der Fehler liegt?

bool Payload::insertElement(int e, int p) {
	try {
		payload->at(p) = e;
		return true;
	}
	catch (out_of_range) {
		std::cout << "Could not insert the element " << e << " at position " << p << endl;
 	}
	return false;
}

payload ist:

payload = new std::vector<int> (0);

Und die Fehlermeldng:
gcc -c frames/Payload.cpp -o Payload.o
frames/Payload.cpp: In member function bool Payload::insertElement(int, int)': frames/Payload.cpp:27: error: syntax error before)' token
make: *** [Payload.o] Fehler 1

Zeile 27 ist die Catch Anweisung!

Danke!

John Doe

Einmal verwendest du explicit den namespace std (std::cout) und ein anderes mal nicht (out_of_range). Da ich nur einen Teil von deinem Code sehe kann ich nur raten das es möglicherweise std::out_of_range heissen müsste ?!?

mfg JJ

Frodus

Erstmal danke,

der Gedanke ist mir auch schon gekommen,
aber das scheint es nicht zu sein.
selbst ein:
using namespace std
oder ein:
std::out_of_rang

resultieren in der gleichen Fehlermeldung.

nman

*dummfrag* Hast Du auch sicher nicht vergessen, <stdexcept> einzubinden?

Frodus

Danke nman,

genau das wars!
Ich Programmiere halt c++ noch nicht so lange
und so oft und die guten Bücher schweigen sich ja da
in den Bsp. meistens aus.

Christoph

volkard

Frodus schrieb:

Hi Leute,
kann mir vielleicht jemand sagen wo hier der Fehler liegt?

bool Payload::insertElement(int e, int p) {
	try {
		payload->at(p) = e;
		return true;
	}
	catch (out_of_range) {
		std::cout << "Could not insert the element " << e << " at position " << p << endl;
 	}
	return false;
}

den formalen haste ja schon. der inhaltliche ist:
das ist java-crap.
wenn man schon exceptions benutzt, dann ist doch was logisches in diesem falle

void Payload::insertElement(int e, int p) {
	payload->at(p) = e;
}

und man fängt sie meinetwegen in der main(). exceptions genau dort zu fangen, wo man auch ein if drum benutzen könnte, ist java-crap. sowas seht man in c++ nicht. insertElement zu ner bool-funktion zu machen, um zu sagen, ob es klappte, ist c-crap. aus einer zeit, bevor es exceptions gab. die fehlerausgabe dann ungefragt nach cout zu klatschen ist nirgends so zu finden. vieleicht bei php, wenn's nicht abgeschaltet ist? die geheimnisse um size_t lassen wir unberührt, es gibt auch gute gründe für int. aber sag mal, die lib bitet ne methode at() an, die genau das anbietet, was du brauchst. sollte dein ding eventuell so lauten?

int& Payload::at(int p) {
	return payload->at(p);
}

und getzt haut mich nich gleich sofort, weil da ne ref zurückgegeben wird und man deshab die daten ändern kann, während in obigem code die daten by value übergeben werden und nicht geändert werden können. obige funktion ändert die daten, was das nicht-ändernkönnen signifikant relativiert.
die at-methode kriegt nur nen gefahrenpunkt für if(foo.at(3)=5)...
sie hätte aber den vortiel, daß sie bereits dokumentiert wäre. man wüßte auch als fremder, der gerade von nem 5-jährigen australientrip wieder in die firma einsteigt, sofort daß diese methode nen size_t als argument nimmt, ne exception wirft, wenn's nicht klappt und ne referenz zurückgibt und sich ansonsten wie ein op[] verhält.

kannse mir noch sagen, welches buch dich dazu inspiriert hat, damit es sofort auf meine black-list kommt?

John Doe

Ich würde folgende Variante bevorzugen:

void Payload::insertElement(int e, int p) {
  try 
    payload->at(p) = e;
  catch (out_of_range) {
    std::cout 
      << "out_of_range Error in Module "
      << __FILE__ <<
      << "at Line " <<
      << __LINE__ << std::endl;
     }
}

Von dem Rückgabe-Wert halte ich auch nichts, da Fehler = Exception => Returncode = bedeutungslos. Andererseits ist es aber möglich das x andere Stellen im Programm irgendwelche Vektoren mit at "bearbeiten". In diesem Fall bringt mich ein zentraler Exception-Handler in main() nicht weiter. Ich will natürlich wissen wo der Fehler aufgetreten ist. Und zu diesem Zweck würde ich irgendeine Ausgabe, zum Beispiel nach cout, an der Stelle einfügen wo der Fehler auftitt, aber in jedem Fall zusammen mit Angaben die exakte Informationen zu Fehlerstelle enthalten.

mfg JJ

volkard

[quote="John Doe"]Ich würde folgende Variante bevorzugen:

void Payload::insertElement(int e, int p) {
  try 
    payload->at(p) = e;
  catch (out_of_range) {
    std::cout 
      << "out_of_range Error in Module "
      << __FILE__ <<
      << "at Line " <<
      << __LINE__ << std::endl;
     }
}

[quote]
dann vielleicht besser:

void Payload::insertElement(int e, int p,ostream &err) {
  try 
    payload->at(p) = e;
  catch (out_of_range) {
    err
      << "out_of_range Error in Module "
      << __FILE__ <<
      << "at Line " <<
      << __LINE__ << std::endl;
     }
}

manchmal will man ja in ne datei, nen socket oder nach cerr die fehler schreiben oder gar nicht wissen.

Andererseits ist es aber möglich das x andere Stellen im Programm irgendwelche Vektoren mit at "bearbeiten". In diesem Fall bringt mich ein zentraler Exception-Handler in main() nicht weiter.

ok, dann bauen wir uns ein ASSERT, das innendrin vor dem throw BlaException(__FILE__,__LINE__,...) ein __asm__ int 3; macht. oder wir nehmen uns solche ein ASSERT einfach mal als fernziel, aber nehmen uns vor, es entweder ganz toll oder gar nicht zu machen.

Ich will natürlich wissen wo der Fehler aufgetreten ist. Und zu diesem Zweck würde ich irgendeine Ausgabe, zum Beispiel nach cout, an der Stelle einfügen wo der Fehler auftitt, aber in jedem Fall zusammen mit Angaben die exakte Informationen zu Fehlerstelle enthalten.

nu ist aber Payload auch nur ne hilfsklasse, wenn da ein fehler angezeigt wird, war der inhaltliche fehler trotdem bestimmt beim aufrufer. wer hat dieses insertElement aufgerufen? findet man eh nur mit dem debugger, daher der vorschlag mit int 3.

die kosten sind auch ganz gering. nur ein wenig stl-verzicht.

John Doe

Also ich seh der Klasse nicht an, das es nur eine "Hilfsklasse" ist. Aber das spielt nur eine untergeordnete Rolle. Wenn ich im Rahmen einer Exception Protokolle führe bzw. andere Fehlerausgaben mache dann ist es sicher immer sinnvoll die Stelle die den Fehler ausgelöst hat zu wissen. Zusammen mit einem sinnvollen "Gesamt"-Tracing kann einem das durchaus näher zur Ursache des Problems bringen. Ich zumindest sitze nur ungern bei jeder passenden/unpassenden Gelegenheit beim Kunden und exerziere irgendwelche Abläufe mit dem Debugger durch, solange ich noch eine andere (sinnvolle) Möglichkeit habe.
Ob ich wirklich sinnvolle Alternativen habe wird dabei ganz sicher schon beim Design und der Implementierung entschieden.
Ich habe schon sehr oft neidvoll auf die überaus sinnvollen Stack-Traces eines Java-Programmes geschaut, mit den es meinen "Java"-Kollegen sehr oft möglich war den Fehler direkt, ohne Debugger, nur mit ein paar Blicken in den Source-Code zu finden, und das ohne zusätzliche "Anstrengungen" bei der Implementierung. C# bzw. .NET geht ja wohl den gleichen Weg hab ich gehört.

mfg JJ

@volkard: Seit wann ist es in Java üblich, eine IndexOutOfBoundsException zu fangen??
Die wird im Allgemeinen nicht gefangen und die muss auch nicht gefangen werden, deshalb ist sie ja von RuntimeException abgeleitet. Sie ist lediglich (netterweise!) da, um UB zu verhindern und sollte beim fertigen Programm überhaupt nicht mehr auftreten.

Frodus

@volkard: Genau so stand dass natuerlich nicht in dem Buch, die
Ausgabe ist auf meinem mist gewachsen, da ich mich noch
nie mit der Fehlerbehandlung von c++ auseinandergestzt habe.
Ich Persönlich finde die lösung mit der ausgabe an err ganz gut.

Auf der Arbeit programmiere ich halt VHDL oder Perl und da gibt es
diese Art der Fehlerbehandlung halt nicht.

Das Buch ist Übrigens:
Die C++ Programmiersprache
Verlag: Addison-Wesley
Autor: Bjarne Stroustrup

volkard

Optimizer schrieb:

Sie ist lediglich (netterweise!) da, um UB zu verhindern und sollte beim fertigen Programm überhaupt nicht mehr auftreten.

hab aber schon sauviel code gelesen, der die schleife per EOFException beenden läßt.

John Doe

volkard

Frodus schrieb:

@volkard: Genau so stand dass natuerlich nicht in dem Buch, die Ausgabe ist auf meinem mist gewachsen, da ich mich noch nie mit der Fehlerbehandlung von c++ auseinandergestzt habe.

ok. dafür isses ganz gut.

Ich Persönlich finde die lösung mit der ausgabe an err ganz gut.

irgendwann fängt ja auch wie windows-programmierung oder 3d-gamez basteln mit open gl an. dann wirste die ausgaben wieder rasmachen. aber egal. mach es einfach, wie dir es jetzt am nützlichsten ist.

Auf der Arbeit programmiere ich halt VHDL oder Perl und da gibt es
diese Art der Fehlerbehandlung halt nicht.

ob dein chef dir das bch "effektiv c++ programmieren" bezahlen würde? das sollte er.

Die C++ Programmiersprachevon Brarne Stroustrup

ach das. das steht schon ewig auf der blacklist für novizen. es ist mir völlig unverständlich, wie min mit diesem wälzer c++ lernen will. es ist ein nachschlagewerk.

volkard schrieb:

Optimizer schrieb:

Sie ist lediglich (netterweise!) da, um UB zu verhindern und sollte beim fertigen Programm überhaupt nicht mehr auftreten.

hab aber schon sauviel code gelesen, der die schleife per EOFException beenden läßt.

Ist so auch nicht gedacht. Ein Stream endet immer mit -1. Aber macht ja nichts, in C++ manche auch genug Leute einiges falsch.

Frodus

Danke erstmal,
meinst Du dass Buch von Scott Meyers?

Das kost ja nur 30Eur. die werde ich wohl von meinem
Chef bekommen!

Christoph

volkard

Frodus schrieb:

meinst Du dass Buch von Scott Meyers?

ja. es ist in der anfangszeit gold wert, weil es einen zu gutem stil führt und dauernd begründet. so mit echten gründen halt.
und denk nur an "effetiv c++ programmeren". kauf nicht, weil es so schön war gleich "mehr effektiv c++ programmieren" oder "effektiv stl" mit ein. die wären nicht gut.
nach "effektiv c++ programmieren" ist gerne das zweite buch, das ich empfehle der stroustrup. naja, den haste ja schon.
und was leichteres zum einsteig bringt bei dir ja nix mehr.

John Doe

Volkard schrieb:

ob dein chef dir das bch "effektiv c++ programmieren" bezahlen würde? das sollte er.

Kurze Zwischenfrage, wo finde ich denn in dem Buch etwas zu der Fehler(Exception)-Abhandlung so wie du sie propagierst.

mfg JJ

In "Mehr effektiv C++ programmieren". Ich bin aber auch der Meinung, dass man erst mal den ersten Teil lesen sollte.

John Doe

Hi Optimizer,

vielleicht sollte ich doch mal PC-Pause machen. Aber ich finde die gesuchten Textpassagen zu Exceptions auch nach 5-minütigem Suchen nicht. Kannst du mir vielleicht auf die Sprünge helfen

mfg JJ

STL vector &quot;at&quot; und try and catch error

STL vector "at" und try and catch error