[A] Exceptions
-
was interessant waere, waere die Exception Implementierung vom gcc. Da weiss nicht zufaellig jemand etwas naeheres?
-
Wichtig: wie soll ich die 3 Exception Garantien (basic,strong,nothrow) in deutsch nennen? Oder soll ich bei den englischen Bezeichnungen bleiben? Der aktuelle mischmasch ist schlecht
Ich bin für Englisch. Bis auf nothrow sind die Namen an sich so nichts sagend, dass man Probleme haben könnte sie im Englischen wieder zu erkennen.
Wichtig: wie nennt man Checked Exceptions - also die Idee dahinter: Fehler die immer auftreten koennen wie FileNotFound im Gegensatz zu programmierfehlern wie NullPointerException? Statisch und Laufzeit sind ziemlich dumme Namen
"Checked Exceptions"? Oder willst du gerne einen eingedeutschten Namen?
Frage: Sollte ich eine komplette Diskussion ueber Checked Exceptions einbauen oder reicht die Erwaehnung dass sie vor und nachteile haben - also so wie es jetzt ist? (links kommen spaeter noch dazu)
Ich glaub das reicht so wie es ist. C++ hat keine also ist es eh nur ein Randthema.
Bei den Exception Spezifikationen solltest du noch erwähnen, dass die nur sehr schlecht mit Funktoren oder templates im Allgemeinen zusammenspielen und in C++ deshalb so gut wie nicht verwendet werden, noch nicht mal in der Standardbibliothek. AFAIK unterstützt der VC sie noch nicht mal (was ich ausnahmsweise mal sogar gut finde). Hier wird die Problematik recht gut beschrieben: http://www.gotw.ca/publications/mill22.htm
was interessant waere, waere die Exception Implementierung vom gcc. Da weiss nicht zufaellig jemand etwas naeheres?
Die Implementierungsdetails sind recht komisch. AFAIK gibt es mehre Modelle welche man beim GCC kompilieren auswechseln kann. Desweiteren hat das GCC Grundgerüst bereits Exceptions und der G++ Frontend stülpt da seine Version noch drüber. So richtig durchblicken tue ich da nicht mehr. Einen Verweis auf die GCC Implementierung ist also nicht so das Wahre.
Ein Model verwendet Cs setjmp und longjmp (sjlj). Das geht dann in etwa folgendermaßen:
void bar(){ throw 3; } void foo(){ string str; vector<int>vec; bar(); }
wird zu
jmp_buf*top_frame; void bar(){ // throw 3; longjmp(*top_frame, 1); } void foo(){ // string str struct string str; str.string(); jmp_buf current_frame, *previous_frame = top_frame; top_frame = ¤t_frame; if(setjmp(current_frame)){ str.~string(); top_frame = previous_frame; longjmp(*top_frame, 1); }else{ // vector<int>vec struct vector<int>vec; vec.vector(); jmp_buf current_frame, *previous_frame = top_frame; top_frame = ¤t_frame; if(setjmp(current_frame)){ vec.~vector(); top_frame = previous_frame; longjmp(*top_frame, 1); }else // bar(); bar(); } }
Es ist aber definitiv nicht die schnellste Art Ausnahmen zu implementieren von daher könnte es Leute abschrecken Ausnahmen überhaupt zu benutzen.
-
Bei Checked Exceptions meine ich die Idee - oder das Konzept. Logik Fehler vs "Runtime Fehler" oder wie auch immer.
Fehler die auftreten koennen auch wenn dein Code 100% korrekt ist - wie nennt man diese Klasse/Art an Fehlern? (im gegensatz zu fehlern die der programmierer selber einbaut: logik fehler, arithmetische fehler, syntax fehler,...)
die GCC implementierung sieht der VC++ implementierung fuer 32bit recht aehnlich - auf den 1. blick zumindest.
rest ist vorgemerkt. danke.
-
Ich glaub dieses Konzept hat keinen Namen.
PS: Poste nächstes mal die Fragen lieber in einem normalen Post im Topic. Ich hatte die nur durch Zufall entdeckt.
-
so, mal wieder ein kleines update gemacht. langsam wird das ja was.
muss mich nur noch dazu durchringen ein komplexes beispiel fuer exception sichere klassen zu bauen
-
In der Einleitung sollte man vielleicht noch auf Exception Handling in C mittels setjmp/longjmp hinweisen.
-
guter punkt. danke.
-
In "Design by Contract" ist der Kommentar im Code "//theoretisch fehlt hier die Überprüfung ob result genug Speicher hat um die ganzen Elemente auch aufzunehmen" zu lang für 1024x768.
Ein Artikel über modernes Exceptionhandling sollte imho Common Lisps Conditions nicht unerwähnt lassen, da es sich bei den Conditions sicher um eines der besten Exceptionsysteme handelt.
http://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
http://dlweinreb.wordpress.com/2008/03/24/what-conditions-exceptions-are-really-about/
-
Ich kapiere den Sinn von restarts nicht wirklich. Klingt fuer mich erstmal ziemlich schmutzig.
Ich kann in einer Funktion restart Punkte setzen wo ich mir denke dass wenn ein Fehler auftritt ich von dort neustarten kann. Aber kann ich garantieren dass ich von _diesem_ fehler der aufgetreten ist recovern kann?
Das Beispiel ist ja OK auf der Seite mit "wenn ich die eine Zeile nicht parsen kann, dann parse ich eben die naechste". Aber was wenn ich die eine Zeile nicht parsen konnte wegen eines externen problems - zB out of memory ist geflogen. Dann kann der caller automatisch neustarten obwohl ich davon nicht recovern kann?
ich kann ja aus mehreren gruenden fehlschlagen - manche fehler sind uU recoverbar aber manche fehler nicht. ich koennte zb meinen parsebaum zerschossen haben nachdem ich die zeile falsch geparst habe - aber nur wenn ein bestimmter fehler auftritt: wie kann ich mit conditions hier unterscheiden?
und vorallem: ist es ueberhaupt sinnvoll dass der caller diese implementationsdetails von mir kennt?
-
Ich verstehe deine Einwände nicht ganz. In der Funktion weißt du ja selbst, von welchen Fehlern du recovern kannst und von welchen nicht. Wenn du also einen Fehler hast von dem du recovern kannst, dann bietest du für die condition restarts an. Wenn nicht, dann eben nicht.
out-of-memory ist ja eine andere condition, als ein malformed-entry-error. (Bei oom könnte man ja auch einen restart durchführen, wenn man Speicher freiräumt.)
Das mit den Implementierungsdetails kann ich auch nicht ganz nachvollziehen.
-
mhm, ich scheine das prinzip nicht verstanden zu haben.
hast du mehr links zu dem thema?
(ich werd es aber nicht einbauen solange ich das prinzip nicht 100% verstanden habe - denn nichts ist schlimmer als halbwahrheiten...)
-
kleines update des artikels