Was ist schneller: Fehlercode oder Exception?
-
und schrieb:
Wenn ich map[key]=value mache und key ist nicht da, dann Ja.
ich habe nicht von std::map geredet. aber ja, da sieht man schoen einen designfehler von std::map. weil man nicht wollte dass container exception ausloesen. nun ja. dafuer muss man dauernd map.find() verwenden wenn man mit maps arbeitet...
-
Bashar schrieb:
weil Exceptions eben objektorientierte Ansatz zur Fehlerbehandlung sind
Ist das so? Was ist es denn, das Exceptions zum objektorientierten Ansatz macht?
RAII?! oder schon mal den return-value vom CTor auf nen Error-Code geprüft? ^^
Oder du gehst den weg überInit ()für jede Klasse, die sonst einen (nicht-trivialen) CTor hätte - aber das halte ich nicht für die beste (weil unübersichtlicher) Möglichkeit...error-codes beschränken aber auch allgemein... was ist, wenn 100de funktionen jedes ma ne andere aufrufen und jedes ma wieder gucken müssen, ob die letzte ok war... wie bekommt man am ende den fehler raus? ok - man macht 100defines... und iwann kommt noch ne fkt zwischendrin dazu - und man muss bei jeder fkt wieder was dazu schreiben, die was damit zu tun hat... Bei exceptions macht man dann gar nix weiter, als die exception einfach so lang weiterzuwerfen, bis sie Verarbeitet / ausgewertet / auf sie reagiert / ... werden kann...
Error-Codes sind IMHO nur sinnvoll, wenn man mit dll`s arbeitet, da IMHO keine exceptions über dll-grenzen hinweg geworfen werden können (kein standardisierte aufbau der variablen (siehe z.bsp. vector und damit auch string - der speicherplatz eines MSVC-std::strings wird binär ausgegeben sicherlich anders sein, als einer unter xyz-erstellter))
bb
-
unskilled schrieb:
RAII?! oder schon mal den return-value vom CTor auf nen Error-Code geprüft? ^^
Oder du gehst den weg überInit ()für jede Klasse, die sonst einen (nicht-trivialen) CTor hätte - aber das halte ich nicht für die beste (weil unübersichtlicher) Möglichkeit...RAII kann ich auch ohne exceptions haben. RAII heisst ja nur, dass ich im DTor aufraeume. Aber ich kann auch den DTor durch ein return aufrufen.
Und statt exceptions koennte man bei einem CTor fehlschlag auch deferred error handling nehmen - wie es zB die fstreams machen wenn open() fehlschlaegt.
In anderen Sprachen kann man das Objekt dann zB auch NULL werden lassen.
error codes sind wahnsinnig umstaendlich, ja. aber exceptions haben nichts objekt orientiertes an sich. ausser dass man exceptions polymoprh verwenden kann - selbes gilt aber auch fuer error codes die returned werden.
also exceptions als OO ansatz zu sehen... ne, ich weiss echt nicht. ich sehe da nichts objekt orientiertes. zumindest nichts dass ich bei error codes nicht auch haben koennte.
aber dass macht exceptions nicht schlecht. denn oop == gut, alles andere == schlecht - stimmt ja nicht.
-
unskilled schrieb:
RAII?! oder schon mal den return-value vom CTor auf nen Error-Code geprüft? ^^
Ich seh nicht, was das mit OO zu tun hat. RAII ist eine C++-Spezialität. Ein Konstruktor könnte auch einfach null zurückgeben, wenn die Sprache das zulässt (ist in Objective-C so, IIRC).