Exception Specifications, GCC

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.