catch(...) fängt meine Exception nicht!

  • Hi!

    Ich habe ein ganz eigenartiges Phänomen! Ich habe eine klasse (ttsserver) implementiert und darin existiert eine public function: connect()!

    nCSCE(..) ist eine Funktion aus einer c-Library und gibt nen int wert zurück! Wo anderst rufe ich

    auf und bekomme "terminate called after throwing an instance of 'ttsserver::NoServerException'"!!
    wenn ich innerhalb der Try { .. } ein throw ttsserver::NoServerException(""); aufrufe wirds richtig gefangen nur das andere nicht!
    Ich programmier jetzt schon ziemlich ziemlich lang (heute) ... und ich find den Fehler nicht! wh. ists eh ganz einfach! aber im Moment hab ich keine Ahnung!

    Thx für die Hilfe (im voraus)

    lg 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 ...)

    µC-Leitung

  • 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.)

    ~~ Ondra „Ravu al Hemio“ Hošek
    I know what PC LOAD LETTER means

    Tutor außer Dienst · OOP · OS · PK · PP

  • 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.

    ~~ Ondra „Ravu al Hemio“ Hošek
    I know what PC LOAD LETTER means

    Tutor außer Dienst · OOP · OS · PK · PP


  • 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.

    µC-Leitung

  • 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.

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!