[A] Exceptions
-
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