also es wird irgendwie eine Exception geschmissen, die ich nicht
zuordnen kann und auch nur über catch(...)
gefangen bekommen.

Hat jemand ne Ahnung wie ich nun mehr Infos bekommen kann was da genau
geschmissen wir ?

Danke

wenn es deine eigene funktion ist, die throw ausführt, weißt du es, sonst sollte es dokumentiert sein.

können eig mehrere sachen gleichzeitig geworfen werden?

können eig mehrere sachen gleichzeitig geworfen werden?

Klar, du brauchst nur nen Objekt von verschiedenen Exceptions ableiten ^^

Oder in 2 Threads *g*

Nein, geht nicht

Ansonsten kannst du über mit "catch(...)" gefangene Sachen garnix rausfinden.

Und "gleichzeitig" können keine Exceptions fliegen, allerdings werden beim Stack-Unwinding Destruktoren aufgerufen, und die können natürlich auch was werfen wenn sie wollen. Wenn das passiert wird das Programm abgebrochen. Was nur einer der Gründe ist warum man in Destruktoren niemals um sich werfen sollte.

Sau blöd ist nur, dass das manche Compiler z.B der von MS (meines Wissens selbst der 2005er) nicht unterstützen. Da hilft nur Doku und beten, dass die Info's stimmen...

...(und einem der Compiler einen auf die Finger hauen, falls man was anderes versucht zu werfen). ...

Leider nicht !
Lt. Standard wird erst zur Laufzeit geprüft (wenn überhaupt), ob eine unerwartete Exception geworfen wird. In dem Fall wird unexpected() aufgerufen, die wiederum üblicherweise terminate() aufruft, das üblicherweise einen abort() durchführt .... sprich: Es hilft gar nichts !

Gruß,

Simon2.

Nein, es müsste nicht in der Header stehen, und es ist auch gut dass es nicht so ist.
Oh mein Gott, die "throw specs" Jünger...

Nur, weil es mich interessiert: Zählst Du mich dazu ? Wer sind in Deinen Augen "throw specs Jünger" ? Und was hast Du gegen sie ?

Gruß,

Simon2.

Tntnet

@Simon2: ich dachte eigentlich du müsstest wohl einer sein, da du das Thema aufgegriffen hast. Was aber natürlich nur meine (freie) Interpretation deiner Worte war... egal, ich will das Thema sowieso nicht diskutieren wenns nicht sein muss

p.S.: was ich gegen sie habe? Sie haben nicht Recht

Nein, wir verweisen lieber auf bestehende Thrads

@Simon2: ich dachte eigentlich du müsstest wohl einer sein, da du das Thema aufgegriffen hast. Was aber natürlich nur meine (freie) Interpretation deiner Worte war... egal, ich will das Thema sowieso nicht diskutieren wenns nicht sein muss

p.S.: was ich gegen sie habe? Sie haben nicht Recht

Neee, ich halte es mit Herb Sutter und verzichte komplett auf sie.
(alledings nicht, weil ich prinzipiell etwas gegen die Idee hätte, sondern weil sie in C++ derzeit mehr Probleme als Lösungen schaffen).

Gruß,

Simon2.

(alledings nicht, weil ich prinzipiell etwas gegen die Idee hätte, sondern weil sie in C++ derzeit mehr Probleme als Lösungen schaffen).

In Java (wo die Semantik eine etwas andere ist) im Übrigen auch. Uaaaah, ich habe das böse Wort gesagt *duck-und-weg*.

(alledings nicht, weil ich prinzipiell etwas gegen die Idee hätte, sondern weil sie in C++ derzeit mehr Probleme als Lösungen schaffen).

In Java (wo die Semantik eine etwas andere ist) im Übrigen auch. Uaaaah, ich habe das böse Wort gesagt *duck-und-weg*.

Vielleicht sollten wir das woanders diskutieren ("per mail" finde ich gerade nicht), aber es würde mich wirklich (und nicht, weil ich Munition für irgendeine Einstellung von mir bräuchte) interessieren, wo Du die Probleme siehst (weil sie mir offensichtlich verborgen sind - aber da meine Javaerfahrung begrenzt ist, kenn eich halt nur die Probleme, die C++ mit seiner Version hat).

Gruß,

Simon2.

Darüber hinaus musst du voraussehen welche Ausnahmen in Zukunft auftreten könnten (u.a. auch von Objekten die du gar nicht kennst oder kennen willst). Wenn du dabei auf Nummer sicher gehen willst und schlicht throws Exception schreibst, hast du im Prinzip lediglich die no-throw-Garantie aufgehoben.

Naja, du musst die Ausnahmen entweder fangen (auch wenn du sie nicht behandeln kannst) oder in deine Signatur packen (auch wenn sie lediglich ein Implementationsdetail sind).

Exceptions die du nach außen wirfst sind ja wohl wahrlich kein Implementierungsdetail, sondern etwas, was den Aufrufer etwas angeht, was er wissen muss. Also ist nichts logischer als diese Information zum Teil der Schnittstelle zu machen. Sorry aber die Idee, dass es sich dabei nur um ein Implementierungsdetail handeln könnte ist völlig absurd. Die Leute flippen alle aus, wenn nicht dokumentiert ist was für Exceptions eine Funktion werfen könnte, ich würde sowas nicht als Implementierungsdetail bezeichnen.

Darüber hinaus musst du voraussehen welche Ausnahmen in Zukunft auftreten könnten (u.a. auch von Objekten die du gar nicht kennst oder kennen willst).

Das führe mal bitte genauer aus.

Wenn du dabei auf Nummer sicher gehen willst und schlicht throws Exception schreibst, hast du im Prinzip lediglich die no-throw-Garantie aufgehoben.

"Nummer sicher", ahja. Ich weiß nicht, jeder, mit dem ich darüber bisher gesprochen habe und der die checked Exceptions nicht mochte, hat sie nicht kapiert.

Leider nicht !
Lt. Standard wird erst zur Laufzeit geprüft (wenn überhaupt), ob eine unerwartete Exception geworfen wird. In dem Fall wird unexpected() aufgerufen, die wiederum üblicherweise terminate() aufruft, das üblicherweise einen abort() durchführt .... sprich: Es hilft gar nichts !

Hab absichtlich nicht geschrieben, dass es im Standard steht, sondern wie es sein sollte.

Wobei wenn ich mich recht entsinne, es durchaus Compiler gibt, die sowas auswerten (lang lang ist es her seit ich was mit dem gcc gemacht habe).

Mag sein, das nicht alle Entwickler dieses Feature bei einem C++-Compiler benötigen. Gibt auch Leute die Klassen als überflüssigen Balast empfinden.

Gerade bei Fremdbibliotheken kann es jedoch ziemlich lästig sein, wenn irgendwo tief unten in nicht sehr leserlichem Binär-Code eine Exception geworfen wird, die man an der Stelle nicht erwartet, deren Typ man nicht kennt und sich das Programm beim Kunden sang und klanglos am besten direkt beendet.
Da wäre ein Compiler, dem es nicht egal ist was wo von wem geworfen wird schon eine ziemliche Hilfe.

Naja, du musst die Ausnahmen entweder fangen (auch wenn du sie nicht behandeln kannst) oder in deine Signatur packen (auch wenn sie lediglich ein Implementationsdetail sind).

Darüber hinaus musst du voraussehen welche Ausnahmen in Zukunft auftreten könnten (u.a. auch von Objekten die du gar nicht kennst oder kennen willst). Wenn du dabei auf Nummer sicher gehen willst und schlicht throws Exception schreibst, hast du im Prinzip lediglich die no-throw-Garantie aufgehoben.

Das muß man doch alles sowieso wissen und dokumentieren !
Also warum nicht per Sprachkonstrukt und vom Compiler geprüft ?
Ist es Dir Lieber, dass Dir Deine Kunden das Gemächt langziehen, weil Du undokumentierte exceptions schmeisst ?

Gruß,

Simon2.

Leider nicht !
Lt. Standard wird erst zur Laufzeit geprüft (wenn überhaupt), ob eine unerwartete Exception geworfen wird. In dem Fall wird unexpected() aufgerufen, die wiederum üblicherweise terminate() aufruft, das üblicherweise einen abort() durchführt .... sprich: Es hilft gar nichts !

Hab absichtlich nicht geschrieben, dass es im Standard steht, sondern wie es sein sollte. ...

Falls das nicht ironisch gemeint war: Dann kennzeichne das bitte zukünftig !

Mathias schrieb:

...
Wobei wenn ich mich recht entsinne, es durchaus Compiler gibt, die sowas auswerten (lang lang ist es her seit ich was mit dem gcc gemacht habe). ..

Glaube ich nicht.
Allein schon durch die Tatsache, dass "keine throws()-spec" interpretiert wird als "throws(*)", macht eine derartige Prüfung zur Compilezeit unmöglich - höchstens ganz banale Fälle kann man damit abfangen - und dafür macht sich bestimmt keiner die Mühe. Wenn ich aber in der Implementation meiner "throw-spec-freien" Funktion (die Du benutzt) in einer späteren Version eine neue exception werfe, darf ich das und Dein Compiler bekommt das Teil nicht mehr zu Gesicht => Kein Test zur Compilezeit mehr möglich.

Was schon erlaubt ist (und evtl. gemacht wird), ist das Abweisen von geerbten Funktionen mit abweichenden throw()-specs (innerhalb derselben Übersetzungseinheit). Sprich: Da, wo die throw-spec als Bestandteil des "Typs" interpretiert werden kann (obwohl es offiziell nicht erlaubt ist -> ISO Kap15.4.12).

Aber es steht explizit drin, dass ein Compiler Folgendes NICHT abweisen darf (ISO 15.4.10):

extern void f() throw(X, Y);

void g() throw(X) {   f(); }

Da wird es schon eng für Compilerhersteller ....

Gruß,

Simon2.