Wenn eine Ausnahme mal nicht gefangen wird...
-
Jo hi auch, ich schreibsel grad an ner Einführung in Exception Handling, und wollte mal fragen wie das nun Ist wenn ne Exception nicht gefangen wird.
Ich meine mir ist shcon klar, dass im endeffekt irgendwann MEISTENS terminate(); und darüber dnan abort(); ausgeführt wird, und das Programm zu einem unnormalen Ende geführt wird.
Soweit so gut, jedoch habe ich gelesen dass, wenn eine Exception in den dem jeweiligen try-Block zugeordneten catch()-Blöcken keinen essentiellen Fänger für sich findet, es zum Stack-Unwinding kommt. Wenn ich das richtig verstanden habe wird dabei der Stack rückwäts (klar last in, first out) ausgelesen und irgendwie doch nach nem Exception Handler gesucht, der passt. Stimmt das?
Wenn ja, was wird durchsucht? unter dem Begriff "eine Ebene höher" kann ich herzlich wenig anfangen, weil ich nicht weiss, oib damit eine try-ebene oder eine Funktions-ebene gemeint ist.Hat jemand ne kurze knappe Erklärung die ich versteh? ^^
-
Also so weit ich das sagen kann wird einfach wirklich Funktion für Funktion nach einem Handler (catch) für die geworfenen Exception gesucht, d.h. der Typ muss halt passen.
Wenn du z.B. in deinem Main ein try-catch mit catch(...) machst, sollte dein Program eigentlich nie mit einer UnhandledException abstürzen, nur was macht man dann an dieser Stelle mit dem Programm, der Kontext wo der Fehler herkam ist halt weg.m.
-
Sprich, wenn sich mein try-Block zu dem die Ausnahme gehört schon in "main()" befindet, kannn nicht weiter "hoch" gegangen werden?
Stolpert er dann bis zum "int main()" ansich hoch, und prüft dabei nochmal alls Handler, oder steigt er direkt aus, weil er schon auf der höchsten Ebene ist?
-
Wenn KEIN passender catch Block gefunden wurde, dann sollte es laut Standard auch NICHT zu Stack-Unwinding kommen.
WENN ein passender catch Block gefunden wurde, dann kommt es zum Stack-Unwinding von dem Punkt wo das "throw" steht bis zu dem passenden catch Block.
Was gibts da sonst noch zu erklären?
Was das Stack-Unwinding selbst angeht - WIE das implementiert ist muss dich nicht interessieren. WAS passiert ist dass alle Objekte mit automatic storage (aka. "lokal" aka "auf dem stack") in der umgekehrten Reihenfolge ihrer Konstruktion zerstört werden, bis zu dem Punkt wo eben der passende catch Block steht.
Genauso ... wie genau der passende catch Block ermittelt wird muss dich nicht interessieren, wichtig ist nur nach welchen Regeln das passiert (und die solltest du eigentlich kennen wenn du C++ programmierst). Und (nur falls das nicht klar sein sollte) bevor der passende catch Block nicht fertig ermittelt wurde wird im übrigen auch kein Stack unwinding gemacht, das passiert erst nachher -- oder eben garnicht wenn kein passender catch Block gefunden wurde.
EDIT: findest du es OK eine Einführung (für wen?) zu schreiben wenn du über das Thema nichtmal selbst bescheid weisst? Ich finde das ziemlich fragwürdig ... schlechte und falsche Infos zu C++ gibts schon genug, da muss man nicht noch eins nachlegen...
-
Es ist mir nicht freiwillig eingefallen (mein Clientel ist mein Systemintegratoren Azubi Grüppchen) und eigentlich sollte auch nur die Anwendung von try catch throw und die Verwendung von Standardtypen und Klassen als Ausnahmetypen beschreiben, das andere ist rein intressehalber
Aus einer Quelle ging hervor, dass wenn eine Ausnahme ausgeklöst wird und diese im zugehörigen try-Block, bzw. den dem try-Block zugewiesenen catch-Blöcken keinen "entdeckt" der die Ausnahme behandelt, es nicht direkt zum ausstieg über "terminate();" kommt sondern erst noch im Programmcode "herumgewühlt" wird.
Ich wollte nur wissen ob das richtig ist, nicht wesentlich mehr
-
Shilka schrieb:
Es ist mir nicht freiwillig eingefallen (mein Clientel ist mein Systemintegratoren Azubi Grüppchen) und eigentlich sollte auch nur die Anwendung von try catch throw und die Verwendung von Standardtypen und Klassen als Ausnahmetypen beschreiben, das andere ist rein intressehalber
Naja, das reicht ja schon. Was willst du denen z.B. antworten wenn dich jmd. fragt wo überall nachgeguckt wird ob's nen passenden catch Block gibt, in welcher Reihenfolge genau, was ein re-throw ist ("throw;"), ...
Shilka schrieb:
Aus einer Quelle ging hervor, dass wenn eine Ausnahme ausgeklöst wird und diese im zugehörigen try-Block, bzw. den dem try-Block zugewiesenen catch-Blöcken keinen "entdeckt" der die Ausnahme behandelt, es nicht direkt zum ausstieg über "terminate();" kommt sondern erst noch im Programmcode "herumgewühlt" wird.
Ich wollte nur wissen ob das richtig ist, nicht wesentlich mehr
Wenn du mit "herumwühlen" das Suchen eines passenden und "aktiven" catch Blocks meinst, dann ja.
Bloss solltest du auch wissen in welcher Reihenfolge welche catch Blöcke angeguckt werden, sonst bringt das ganze nix.
-
hustbaer schrieb:
Wenn KEIN passender catch Block gefunden wurde, dann sollte es laut Standard auch NICHT zu Stack-Unwinding kommen....
Also das sehe/finde ich anders:
Spec. 15.3 - Handling an exception schrieb:
...9 If no matching handler is found in a program, the function
terminate()is called; whether ir not the stack is unwound before this call toterminate()is implementation.defined ...Dasselbe steht nochmal in 15.5.1.2. - bezogen auf ungefangene Exceptions.
(Es gibt aber auch Fälle, in denen der Standard vom stack unwindung "abrät" ("...shall not be unwound ...") oder das Vervollständigen untersagt "...is not permitted to finish stack unwindung ...", aber das bezieht sich IMO nicht auf ungefangene Exceptions.)Mir ist zwar kein Compiler bekannt, der diese "Lücke ausnutzt" und mir fällt auch kein sinnvoller Grund dafür ein, aber das bedeutet noch nicht, dass es das nicht geben könnte/dürfte.
Gruß,
Simon2.
-
@Simon2
Nur eine kleine Anmerkung: wenn im C++ Standard irgendwo "shall not" steht, dann ist das kein "abraten", sondern ein Verbot. "shall not" heißt im Sinne des Standards also nicht "sollte nicht", sondern "darf nicht, wenn es standard-konform sein soll". Wenn sich also eine Implementation nicht an ein "shall not" hält, so ist dies schlicht nicht standard-konform.
-
HumeSikkins schrieb:
@Simon2
Nur eine kleine Anmerkung: wenn im C++ Standard irgendwo "shall not" steht, dann ist das kein "abraten", sondern ein Verbot. "shall not" heißt im Sinne des Standards also nicht "sollte nicht", sondern "darf nicht, wenn es standard-konform sein soll". Wenn sich also eine Implementation nicht an ein "shall not" hält, so ist dies schlicht nicht standard-konform.
Das hatte ich mir schon gedacht. (hätte ich wohl "versmilien" sollen)
Ich war nur ein wenig amüsiert, dass direkt hintereinander ein "shall not" und ein "not permitted" stehen ... und die empfinde ich umgangssprachlich als recht unterschiedlich.Gruß,
Simon2.
-
Simon2 schrieb:
hustbaer schrieb:
Wenn KEIN passender catch Block gefunden wurde, dann sollte es laut Standard auch NICHT zu Stack-Unwinding kommen....
Also das sehe/finde ich anders:
Spec. 15.3 - Handling an exception schrieb:
...9 If no matching handler is found in a program, the function
terminate()is called; whether ir not the stack is unwound before this call toterminate()is implementation.defined ...Dasselbe steht nochmal in 15.5.1.2. - bezogen auf ungefangene Exceptions.
(Es gibt aber auch Fälle, in denen der Standard vom stack unwindung "abrät" ("...shall not be unwound ...") oder das Vervollständigen untersagt "...is not permitted to finish stack unwindung ...", aber das bezieht sich IMO nicht auf ungefangene Exceptions.)Mir ist zwar kein Compiler bekannt, der diese "Lücke ausnutzt" und mir fällt auch kein sinnvoller Grund dafür ein, aber das bedeutet noch nicht, dass es das nicht geben könnte/dürfte.
Gruß,
Simon2.
Ups, sorry. Hatte das falsch in Erinnerung
-
hustbaer schrieb:
..
Ups, sorry. Hatte das falsch in ErinnerungNaja, für Viele (mich eingeschlossen) ist es erstmal die unheimliche Offenbarung, dass "stack unwindung" NICHT IMMER bei fliegenden Exceptions durchgeführt wird - daneben ist die theoretische Möglichkeit, dass es irgendjemand doch mal machen könnte, wohl unwichtig.
Gruß,
Simon2.
