Exception Specifications, GCC

Jordy

Hi!

Ich habe grade mal getestet wie sich VC++ bei der Verwendung von Excpetion-Spefikationen verhält. Schlicht enntäuschend. Selbst VC++2005 ignoriert Excpetion-Spezifikationen fast völlig, sowohl zur Laufzeit also auch zu Compile-Zeit. Die meisten Spezifikationen (zumindest mit konkretem Typ) werden mit Warnung ignoriert. VC++ scheint hier zu versagen.

Mit GCC habe ich auch mal versucht zum compilieren, was ich dem VC2003 vorgesetzt habe. GCC scheint folgendes nicht zu begreifen:

void foo() throw(...)
{
}

und gibt auch ansonsten keinerlei Compile-Zeit-Fehler aus. Das scheint aber beides dem C++ Standard zu entsprechen. Weiß jemand ob GCC auch darüber hinaus mit Ausnahme-Spezifikationen vernünftig umgeht? Gibt es noch andere Compiler (windows, linux) die diesbezüglich den Standard achten? Viele Kommentare die ich (online) gefunden habe, sprechen davon, daß die meisten Compiler damit nicht zurecht kommen (allerdings sind solche Äußerungen meist schon veraltet).

Dann noch allgemein wegen des GCC: mit dem (aktuellen) GCC kenne ich mich nicht aus und ich habe beinahe nichts zu obigem Thema gefunden (inwieweit GCC Ausnahme-Spezifikationen unterstüzt). Kann mir jemand für die Zukunft sagen, wo ich Details zum GCC 4 finden kann? Gibt es gute Online-Dokus die über die Offizielle Dokumentation hinaus gehen und in denen man auch vernünftig *suchen* kann? Vielleicht gibts aktuelle Bücher mit gutem Index?

Danke!

7H3 N4C3R

void foo() throw(...)
{
}

Hä? Was soll denn das? Wenn Du willst, das alles geworfen werden kann, dann lass sie weg. Exception-Specs werden erst zur Laufzeit geprüft.

Ausm Standard:
15.4 clause 1: [...] An type denoted in an exception-specification shall not denote an incomplete type. [...]

Ich würde jetzt mal so sagen, dass "..." kein vollständiger Typ ist.

Jordy

7H3 N4C3R schrieb:

void foo() throw(...)
{
}
Hä? Was soll denn das? Wenn Du willst, das alles geworfen werden kann, dann lass sie weg. Exception-Specs werden erst zur Laufzeit geprüft.

Ausm Standard:
15.4 clause 1: [...] An type denoted in an exception-specification shall not denote an incomplete type. [...]

Ich würde jetzt mal so sagen, dass "..." kein vollständiger Typ ist.

Klar. Ich habe auch nichts gesagt daß es gut ist. Ich habe nur festgestellt, daß VC sowas nimmt. Vermutlich weil es Spezifikationen *mit* Typ überhauptnicht beachtet.

Keine Ideen zu meinen Fragen?

Jester

Was heißt denn erbeachtet sie nicht?
Hast Du Code, der das aufzeigt?

7H3 N4C3R

Dass zumindest ältere Versionen vom VC nicht sonderlich standard-kompatibel sind, ist hinreichend bekannt. Zumal dein Beispielcode auch kein gültiges C++ ist. Hab extra nochmal nachgelesen (15.3) - die Ellipsis (...) hat da nix zu suchen.

void klaus() throw (int)
{
   throw double(5);
}

Das wird unexpected() aufrufen, was wiederum terminate() aufruft und dein Programm beendet. Das sind eigentlich Standardabläufe, die viele Compiler unterstützen.

groovemaster

Jordy schrieb:

VC++ scheint hier zu versagen.

Was heisst hier "versagen"? Wie wärs, wenn du dir mal die Doku zum MSC durchliest C++ Language Reference, Exception Specifications

7H3 N4C3R

Auch noch ein wenig Lesestoff für Jordy und alle anderen interessierten:
http://www.gotw.ca/publications/mill22.htm

Superkurzfassung:
Moral #1: Never write an exception specification.
Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.

Edit:
Noch mehr interessantes dazu:
http://www.gotw.ca/gotw/082.htm

Jordy

groovemaster schrieb:

Jordy schrieb:

VC++ scheint hier zu versagen.

Was heisst hier "versagen"? Wie wärs, wenn du dir mal die Doku zum MSC durchliest C++ Language Reference, Exception Specifications

Na, es versagt aus zwei Gründen: Zum ersten akzeptiert es throw(...), was nicht konform ist, und zweitens gibt es bei throw(typ) folgende Warnung aus: warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow), was auch nicht konform ist. Das heißt es werden nur throw() und throw(...) akzeptiert. Das nenne ich versagen.

Vergiss Exception Specifications und gut is

Jordy

vergessen! schrieb:

Vergiss Exception Specifications und gut is

Darauf läufts hinaus, wenn man obige Links liest. Das größte Problem ist meines Erachtens: Was passiert wenn meine Spezifikationen nicht stimmen? Zu Compilzeit kann man das nicht ohne weiteres entdecken, außer man geht manuell alle Funktionen durch, immer unter dem Risko das man Vieles übersieht. Und dann wird das Programm beendet, obwohl es eigentlich fehlerfrei funktioniert.

Gibt es Tools, die versuchen Exception-Spezifikationen per Compilezeit-Analyse zu prüfen? Soetwas müsste unter bestimmten Einschränkungen möglich sein.

Ich erinnere mich an ein Tool, das zur Compilezeit (!!!) die Einhaltung von vordefinierten Wertebereichen von Funktions-Parametern überprüft hat. Das ganze war ziemlich komplex und hat viel Rechenzeit verbraucht wenn die Schachtelungstiefe zunahm, aber letztendlich hat es recht gut funktioniert.

Im Prinzip ähnelt das der Aufgabenstellung der Einhaltung von Exceptions-Spezifikationen.

Ringding

Jordy schrieb:

Gibt es Tools, die versuchen Exception-Spezifikationen per Compilezeit-Analyse zu prüfen?

Ja, Java. Und du siehst, wie mühsam es dort ist.

Soetwas müsste unter bestimmten Einschränkungen möglich sein.

Richtig, aber die Einschränkungen sind ziemlich drastisch.

Jordy

Ringding schrieb:

Jordy schrieb:

Gibt es Tools, die versuchen Exception-Spezifikationen per Compilezeit-Analyse zu prüfen?

Ja, Java. Und du siehst, wie mühsam es dort ist.

Soetwas müsste unter bestimmten Einschränkungen möglich sein.

Richtig, aber die Einschränkungen sind ziemlich drastisch.

Aber für C++ hat deines Wissens nach noch niemand sowas versucht?

7H3 N4C3R

Du kannst das Problem haben, dass Du mit Bibliotheken arbeitest, von denen Du nicht weißt, ob sie mal eine Exception werfen. So kann Code, der Tage, Wochen oder Monate einwandfrei funktionierte plötzlich versagen. Versuch lieber exception-sicheren Code zu schreiben anstatt dich an den Exception-Spezifikationen aufzuhängen. Dazu gibt's im "Guru of the Week" oder im ausgelagerten Buch davon (Exceptional C++) gute Anleitungen.

Das Tool das Du meinst, könnte Flexelint sein

Jordy

7H3 N4C3R schrieb:

Du kannst das Problem haben, dass Du mit Bibliotheken arbeitest, von denen Du nicht weißt, ob sie mal eine Exception werfen. So kann Code, der Tage, Wochen oder Monate einwandfrei funktionierte plötzlich versagen. Versuch lieber exception-sicheren Code zu schreiben anstatt dich an den Exception-Spezifikationen aufzuhängen. Dazu gibt's im "Guru of the Week" oder im ausgelagerten Buch davon (Exceptional C++) gute Anleitungen.

Das Tool das Du meinst, könnte Flexelint sein

"PC-Lint" wenn ich mich recht erinnere
Ist das identisch?

Ja, klar, die Bibliothken sind ein Knackpunkt. Wenn man aber z.B. Bibliotheken verwendet, die, wie meine im Augenblick, grundsätzlich *garkeine* Exceptions werfen (ausgenommen der Standard-Exceptions der C++-Runtime) dann ist das kein großes Problem.

kartoffelsack

Jordy schrieb:
Gibt es Tools, die versuchen Exception-Spezifikationen per Compilezeit-Analyse zu prüfen?
Ja, Java. Und du siehst, wie mühsam es dort ist.

Zitat:
Soetwas müsste unter bestimmten Einschränkungen möglich sein.
Richtig, aber die Einschränkungen sind ziemlich drastisch.

Ich find es eigentlich eine Schwäche von C++. Weil man jeden Typ throwen kann, kann eine Funktion ohne exception-Spezifikation alles werfen und eine zweite Funktion die erstere Benutzt kann nicht sagen, was geworfen wird, außer sie würde mit einem ein catch(...) alles fangen.
Dafür dann Tips, dass man das nothrow besser in den Kommentar schreibt. Und das bei C++, wo es doch alle so geil finden, dass man dank Templates etc. alles zur Compile-Zeit prüfen kann.

Unter Java sind Exception Specifications eine Qual!

groovemaster

Jordy schrieb:

Na, es versagt aus zwei Gründen: Zum ersten akzeptiert es throw(...)

Und wo ist das Problem dabei? Noch nie was von Compilererweiterungen gehört?

Jordy schrieb:

und zweitens gibt es bei throw(typ) folgende Warnung aus: warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow), was auch nicht konform ist.

Nun, kein Compiler unterstützt den Standard zu 100%. Bisher wurde dies beim MSC nicht integriert, da es zu viel Arbeit für zu wenig Nutzen war (wenn ich da einige Artikel noch richtig in Erinnerung habe). Vielleicht hast du ja bei kommenden Versionen mehr Glück.