Zitat von Leocor

Code

void ttsserver::connect() throw(){

There's your problem.

mit throw() sagst du dem Compiler dass die Funktion nichts wirft. Der checkt das aber nicht zur compile-time. Die Laufzeitumgebung weiß das aber und knallt dir eine weil eine nicht erwartete Exception geworfen wird.

Im Allgemeinen würde ich bei C++ keine throw angeben, das macht man in der Doku/den Kommentaren.
Im Gegensatz dazu zelebriert Java das Angeben mittels throws ja ziemlich stark.
Hat alles seine Vor- und Nachteile (wobei ich mich über einen compile-time check bei C++ schon freuen würde ...)

Zitat von Leocor

Wenn der Compiler wenigstens ein Warning wirft wäre das schon fein!!

Dann müsste aber der Compiler vor allem bei bereits Kompiliertem wissen, ob die dortigen Funktionen/Methoden irgendwelche Exceptions werfen und, wenn ja, welche.

Überhaupt ist die Verwendung von solchen dynamic exception specifications als deprecated erklärt worden (§ 15.4.17) -- immerhin haben sich die äquivalenten checked exceptions als eine der größten Designfehler von Java herauskristallisiert, und für Optimierungszwecke gibt es die Alternative noexcept (§ 15.4.1ff), die explizit ankündigt, dass eine Funktion/Methode gar keine Exceptions wirft. (Womöglich gibt es dann eine Warnung, wenn du versuchst, Exceptions vom Aufruf einer noexcept-Funktion/Methode zu fangen.)

(Verwiesen wird hier auf die entsprechenden Abschnitte des C++11-Standards, dessen letzter Entwurf N3337 frei zur Verfügung steht.)

Zitat von Ravu al Hemio

Dann müsste aber der Compiler vor allem bei bereits Kompiliertem wissen, ob die dortigen Funktionen/Methoden irgendwelche Exceptions werfen und, wenn ja, welche.

Ja, das wäre schön.

Zitat

immerhin haben sich die äquivalenten checked exceptions als eine der größten Designfehler von Java herauskristallisiert

Nun ja, ich weiß, dass die manchmal nerven (mich eingeschlossen) und viele sich um Exceptions einfach nicht kümmern (wollen) bzw. nicht wenige überhaupt nicht wissen wofür die eigentlich gut sein sollen. Dennoch finde ich sie nach wie vor gut, wenn man sie richtig einsetzt. Und, in zumindest so einigen Situationen, findet dann (wie man hier im Thread sieht) einige Fehler auch der Compiler (gerade bei der meist unbeliebten Fehlerbehandlung) und man entdeckt diese nicht erst bei den Tests (wenn die denn gut gemacht sind) - oder eben auch nicht.

Exceptions selbst sind in Ordnung. Checked Exceptions zwingen dich unterschwellig, die Exceptions so tief im Code wie möglich abzufangen (weil du sonst deine API mit throws-Klauslen vollpfeffern musst), was nicht immer sinnvoll ist.

Zitat von Ramses13

Ja, das wäre schön.

Theoretisch könnte man das in die Objektfile reinpacken. Wird halt sicher nicht gerade so eine einfache Implementierung werden wenn die Exception die ein Funktion in Objectfile A wirft, im Objectfile B deklariert ist, welche wiederum von eine anderen Exception abgeleitet wurde die in Objectfile C steckt.

Ich denke das größere Problem ist doch eher die Tatsache das `new` im Normalfall einen std::bad_alloc wirft wenn der Memory aus ist. Alleine bei so etwas überall eine Behandlung machen oder `throw()` deklarieren ist hochgradig uninteressant.

Zitat von Ravu al Hemio

Exceptions selbst sind in Ordnung.

Das sowieso.

Zitat

Checked Exceptions zwingen dich unterschwellig, die Exceptions so tief im Code wie möglich abzufangen (weil du sonst deine API mit throws-Klauslen vollpfeffern musst), was nicht immer sinnvoll ist.

Nun ja, Exceptions früh zu fangen finde ich nichts schlechtes dabei. Problematisch ist nur, wenn man sie an einer ungeeigneten Stelle fängt (da gehört wie immer beim Programmieren Disziplin dazu) und noch schlimmer wenn man Fehler gar nicht behandelt bzw. übersieht zu fangen (und da helfen Checked Exceptions).
Und ja, (Checked) Exceptions quer durch ein Programm zu schleifen finde ich grundsätzlich auch nicht gut, aber das ist auch eher die Ausnahme (und da überwiegt meist der Nutzen die Nachteile deutlich und wenn Unchecked Exceptions an einer Stelle notwendig sind, dann gibt es die ja auch). Außerdem sehe ich bei Checked Exceptions nicht mehr Ärgernisse, als wenn man z.B. von einer Programmiersprache gezwungen wird Typen anzugeben, oder einen Parameter über mehrere Methoden mitzuschleppen, weil er vielleicht irgendwo gebraucht wird.

Zitat von skinner33

Theoretisch könnte man das in die Objektfile reinpacken. Wird halt sicher nicht gerade so eine einfache Implementierung werden wenn die Exception die ein Funktion in Objectfile A wirft, im Objectfile B deklariert ist, welche wiederum von eine anderen Exception abgeleitet wurde die in Objectfile C steckt.

Ja, C/C++ kann einem ganz schön auf die Nerven gehen. Oder wie meinen?

Zitat

Ich denke das größere Problem ist doch eher die Tatsache das `new` im Normalfall einen std::bad_alloc wirft wenn der Memory aus ist. Alleine bei so etwas überall eine Behandlung machen oder `throw()` deklarieren ist hochgradig uninteressant.

Exceptions, die überall geworfen werden könnten, sind natürlich keine sinnvollen Kandidaten für Checked Exceptions. Genauso bei einem Stack Overflow, oder wenn in C/C++ wieder mal ein Pointer ins Leere geht.