Exceptions in C++ hui oder pfui?
-
dot schrieb:
Nö, ich mein eigentlich das: http://msdn.microsoft.com/en-us/library/a4xbdz1e.aspx
Damit kann beispielsweise jeder Entwickler des Teams an bekannten Orten (z.B. MSBuild Extensions Directory) Property Sheets für alle möglichen Versionen aller möglichen Libs und SDKs die er so installiert hat ablegen.
Ein VC++ Projekt verweist dann einfach auf die entsprechenden .props Dateien der benötigten libs und fertig. Damit kann jeder Entwickler seine Dateien organisieren wie er will und auch 100 verschiedene Versionen aller möglichen libs halten und trotzdem funktioniert jedes Projekt einfach so out of the box. Da muss ich dann weder irgendwelchen Code irgendwohin kopieren noch irgendwelche libs irgendwo eintragen. Und nur weil Visual Studio selbstverständlich eine GUI zum Editieren von Propery Sheets bietet, heißt das noch lange nicht, dass ich auf die angewiesen bin. Die GUI ist doch nur ein bequemes Interface zum Buildsystem.
Mit deiner Zeile Code wär das imo überhaupt nicht besser gelöst, denn das pragma ist plattform-/compilerspezifisch und kommt mit verschiedenen Versionen, Suchpfaden, etc. rein prinzipiell schon nicht klar. Sowas gehört eben einfach nicht in den Code, genau für sowas gibts doch überhaupt erst ein Buildsystem...Und ich habe das Gefühl, daß die Property Sheets genau gar nichts von dem lösen, was mich interessiert.
Das Argument "Sowas gehört nicht dahin" ist zwar traditionell, aber nicht stark. Verscjiedene lib-Versionen sind auch nicht mein Problem.Am Ende ist es wohl so, daß wir andere große Ärgerlichkeiten in Projekten hatten und jeweils Auswege für diese Ärgerlichkeiten gefunden haben und zum persönlichen Stil gemacht haben. Ohne, daß der andere Stil jetzt per se schlechter wäre.
-
314159265358979 schrieb:
weil die Syntax so unglaublich umständlich und hässlich ist.
Umständlicher und hässlicher als
result = callSomeFunction(useful_arg, that_damn_error_code); if (that_damn_error_code != SOME_MAGIC_NUMBER_INDICATING_ALL_GOOD) { wtf(lookup(that_damn_error_code)); }nach diversen Funktionsaufrufen? Ich weiß ja nicht...
-
try { gimme_that_from_config; try { do_that_with_the_value; } catch(omg_no_workz) { cout << "shit happens\n"; } } catch(what_was_the_name_of_that_error_that_indicates_that_the_value_doesnt_exist_in_the_config_file) { cout << "you are wasting my time\n"; }
-
-
Denk dir halt nach dem inneren catch noch was dazu.
-
314159265358979 schrieb:
Denk dir halt nach dem inneren catch noch was dazu.
-
-
Oder man schaut einfach mal bei Lisp nach wie man es richtig macht: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
-
niemand schrieb:
vorschlag schrieb:
Verlinkt doch mal ein Open Source C++ Projekt, dass eurer Meinung nach Exceptions effektiv verwendet.
Da schau ich nur 2 Dateien an und finde in der 2ten eine Methode die ewig viele Parameter hat, fast 200 Zeilen lang ist und folgendes enthält.
291 catch (const Exception & e) 292 { 293 std::cerr << "When processing '" << *q << "' got exception '" << e.message() << "' (" << e.what() << ")" << std::endl; 294 retcode |= 1; 295 }
-
vorschlag schrieb:
niemand schrieb:
vorschlag schrieb:
Verlinkt doch mal ein Open Source C++ Projekt, dass eurer Meinung nach Exceptions effektiv verwendet.
Da schau ich nur 2 Dateien an und finde in der 2ten eine Methode die ewig viele Parameter hat, fast 200 Zeilen lang ist und folgendes enthält.
291 catch (const Exception & e) 292 { 293 std::cerr << "When processing '" << *q << "' got exception '" << e.message() << "' (" << e.what() << ")" << std::endl; 294 retcode |= 1; 295 }Erklärung?
-
Was hat das mit sinnvollem verwenden von Exceptions zu tun, wenn man sie wieder zu return codes umwandelt wie ohne Exceptions? Und dann noch return code 1.
-
vorschlag schrieb:
Was hat das mit sinnvollem verwenden von Exceptions zu tun, wenn man sie wieder zu return codes umwandelt wie ohne Exceptions? Und dann noch return code 1.
Dir ist schon klar, dass sich der try-catch-Block innerhalb einer Schleife befindet, die offenbar nicht beendet werden soll, bloß weil eine erwartete Exception auftritt? Wahrscheinlich nicht. Immerhin werden interne Fehler weitergeworfen, es scheint sich also jemand Gedanken gemacht zu haben.
-
camper schrieb:
vorschlag schrieb:
Was hat das mit sinnvollem verwenden von Exceptions zu tun, wenn man sie wieder zu return codes umwandelt wie ohne Exceptions? Und dann noch return code 1.
Dir ist schon klar, dass sich der try-catch-Block innerhalb einer Schleife befindet, die offenbar nicht beendet werden soll, bloß weil eine erwartete Exception auftritt? Wahrscheinlich nicht. Immerhin werden interne Fehler weitergeworfen, es scheint sich also jemand Gedanken gemacht zu haben.
Sozusagen Exceptions zur Ablaufsteuerung. Und Exception ist auch gut gewählt für erwartete Exceptions, fast so gut wie 1.
-
vorschlag schrieb:
camper schrieb:
vorschlag schrieb:
Was hat das mit sinnvollem verwenden von Exceptions zu tun, wenn man sie wieder zu return codes umwandelt wie ohne Exceptions? Und dann noch return code 1.
Dir ist schon klar, dass sich der try-catch-Block innerhalb einer Schleife befindet, die offenbar nicht beendet werden soll, bloß weil eine erwartete Exception auftritt? Wahrscheinlich nicht. Immerhin werden interne Fehler weitergeworfen, es scheint sich also jemand Gedanken gemacht zu haben.
Sozusagen Exceptions zur Ablaufsteuerung. Und Exception ist auch gut gewählt für erwartete Exceptions, fast so gut wie 1.
Ist da jetzt irgendwie ein Argument drin?
-
Nein. Alles perfekt. Hast mich vollkommen überzeugt.
-
314159265358979 schrieb:
try { gimme_that_from_config; try { do_that_with_the_value; } catch(omg_no_workz) { cout << "shit happens\n"; } } catch(what_was_the_name_of_that_error_that_indicates_that_the_value_doesnt_exist_in_the_config_file) { cout << "you are wasting my time\n"; }Kannst du auch ein vernünftiges Beispiel liefern?
Also eines, wo ein vernünftiger Mensch auch Exceptions werfen würde, und inklusive dem Exception-freien Ersatzcode?Ich vermute nämlich, dass du einfach sauber programmieren im Allgemeinen leid bist. Weil es halt naturgemäss (viel) mehr Aufwand ist als einfach irgendwas reinhacken, und sich dann freuen dass es funktioniert (so halt keine Fehler auftreten).
-
hey mädels?
in der artikelsammlung stehen midnestens 3 artikel zu dem thema exception handling. ich muss leider zugeben dass ich mich damit noch nie beschäftigt habe und auch eben diese artikel nicht gelesen habe, aber ist das alles quatsch was da drin steht? oder nix wert?
wenn ja, wieso schreibt das keiner einfach mal neu?
und wenn nein, wieso flamt ihr euch hier gegenseitig zu?
exceptions sind teil von C++ und das standard kommitee wird sich sicherlich was dabei gedacht haben, genau wie die compiler hersteller wenn die exceptions unterstützt werden oder auch nicht (ich denke an exception spezifikationen...)und das java das alles was übertreibt und da was strikter ist, hat sicherlich auch seine gründe (ihr wisst ja, ob ein java programm funktioniert ode rnicht, das hängt von 10000 verschiedenen faktoren ab, einschliesslich dem wetter in nordsibirien!). vielleicht implodiert ja das universum wenn eine JRE eine exceptionen fangen muss die der programmierer nicht abgefangen hat...
-
Exception Specifications sind nun zum Glück eh deprecated
-
Hui,
da kamen ja einige Antworten zusammen. Ich denke ich werde wohl doch meinen eigenen Erfahrungen mit Exceptions unter C++ sammeln müssen, da sich die Leute hier alles andere als einig über die Anwendung zu sein scheinen.
Danke erstmal an alle die sich einen Kopf gemacht habe und dass dann hier auch niedergeschrieben haben.
Gruß Chris
-
cfoobar schrieb:
Ich denke ich werde wohl doch meinen eigenen Erfahrungen mit Exceptions unter C++ sammeln müssen, da sich die Leute hier alles andere als einig über die Anwendung zu sein scheinen.
Das solltest du auf jeden Fall tun. Allerdings solltest du dich erst darüber informieren, wie man exceptionsicheren Code schreibt, bevor du mit try/catch-Kaskaden anfängst, Mist zu schreiben
Gute Anlaufstelle: www.gotw.ca/gotw - da gibts einige Artikel über Exceptionsicherheit.
