C++0x checked exceptions?
-
Simon2 schrieb:
asc schrieb:
...
P.S: Tatsächlich würde ich mir von C++ Standard noch 2 Sachen wünschen:
a) Eine portable Definition um über Schnittstellen auch mit C++ Elementen Daten auszutauschen (Auch über Compilergrenzen hinweg).
b) Eine UI-Bibliothek die auch tatsächlich die Standardlib einsetzt (Sprich auch mit std::string, std::wstring etc. klar kommt).c) Ein vernünftiger Umgang mit Datum/Zeit.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2615.html, letzte Woche glaub' ich verabschiedet.
otze schrieb:
d) ein vernünftiger und portabler weg für unicode streams.
http://en.wikipedia.org/wiki/C%2B%2B09#New_string_literals
Ich hätte die Module gerne gesehen.
-
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2615.html, letzte Woche glaub' ich verabschiedet.
Nicht das was Simon2 meinte. Das da oben ist ja wohl sehr low level, mehr für Threading u.ä.
Für TR2 ist aber Boost.date vorgeschlagen. DAS ist Zeit/Datums-Behandlung.
-
.filmor schrieb:
otze schrieb:
d) ein vernünftiger und portabler weg für unicode streams.
String != Stream. Ohne vernünftiges Handling nutzen die Literale außerdem gar nichts. Und soweit ich weiß, ist da nichts geplant (also z.B. Unicode-Normalisierungen, Konvertierungen etc.).
-
Konrad Rudolph schrieb:
.filmor schrieb:
otze schrieb:
d) ein vernünftiger und portabler weg für unicode streams.
String != Stream. Ohne vernünftiges Handling nutzen die Literale außerdem gar nichts. Und soweit ich weiß, ist da nichts geplant (also z.B. Unicode-Normalisierungen, Konvertierungen etc.).
Naja, wenn die Sprache die Literale beherrscht gehe ich doch stark davon aus, dass codecvt-Facetten dafür implementiert werden.
-
Konrad Rudolph schrieb:
fricky schrieb:
blöd finde ich programmiersprachen, mit der man exceptions stillschweigend ignorieren kann. solche exceptions sind kein bisschen besser, als simple rückgabewerte.
Behauptung ohne Beleg.
beleg? hast du schon mal vergessen einen rückgabewert auszuwerten? das ergebnis ist fast das gleiche: meistens ein absturz.
Konrad Rudolph schrieb:
Außerdem: Du findest es also doof, dass Java neben den Checked Exceptions auch Unchecked Exceptions kennt?
nö, das ist ein guter kompromiss. low-level exceptions zu 'checken', die in jeder zweiten programmzeile auftreten können, wäre etwas übertrieben.
tfa schrieb:
fricky schrieb:
blöd finde ich programmiersprachen, mit der man exceptions stillschweigend ignorieren kann. solche exceptions sind kein bisschen besser, als simple rückgabewerte.
Welche Sprache findest du dann nicht blöd?
z.b. auch solche, die exceptions überhaupt nicht kennen. entweder man machts gleich richtig, oder man lässt's bleiben.
tfa schrieb:
Außerdem werden die Exceptions ja nicht komplett ignoriert wie etwa Rückgabewerte. Sie werden nach oben geworfen und führen ltztlich zum Programmabbruch bzw. einem Fehlerreport. Was will man mehr?
ich will z.b. manchmal auf exceptions reagieren, weil es 'ne möglichkeit gibt was zu retten. ich finde es ganz praktisch wenn mir ein compiler sagt: 'hey, hier könnte das und das schief laufen, also mach was dagegen oder wirf die exception weiter'. das trägt einiges dazu bei, stabilen code zu schreiben. ganz doof ist es, wenn's vom compiler nicht die geringste warnung gibt und man für jede funktion in die doku schauen muss, um herauszufinden, ob überhaupt und welche exceptions denn nun generiert werden.
-
fricky schrieb:
ich will z.b. manchmal auf exceptions reagieren, weil es 'ne möglichkeit gibt was zu retten. ich finde es ganz praktisch wenn mir ein compiler sagt: 'hey, hier könnte das und das schief laufen, also mach was dagegen oder wirf die exception weiter'. das trägt einiges dazu bei, stabilen code zu schreiben. ganz doof ist es, wenn's vom compiler nicht die geringste warnung gibt und man für jede funktion in die doku schauen muss, um herauszufinden, ob überhaupt und welche exceptions denn nun generiert werden.
in der theorie korrekt, die praxis sieht aber komplett anders aus. es hat sich erwiesen dass exception spezifikationen (und checked exception sind nichts anderes als strenge exception spezifikationen) die produktivitaet senken und die code qualitaet nicht steigern.
ich will jetzt nicht so weit gehen und sagen checked exception senken die qualitaet, aber es gibt keine sprache in der man mehr
try { foo(); } catch(Exception e) {}findet als in java.das problem mit checked exception ist eben, dass sie die probleme die man hat nur verschieben aber nicht loesen. insofern sind sie nicht schlecht, sie machen ja nicht mehr probleme - sie tauschen nur alte gegen neue -> aber das lohnt eben nicht.
-
.filmor schrieb:
Naja, wenn die Sprache die Literale beherrscht gehe ich doch stark davon aus, dass codecvt-Facetten dafür implementiert werden.
Das standardkommitee hat unicode streams abgelehnt. Wenns die nicht gibt, warum dann codecvt?
-
fricky schrieb:
beleg? hast du schon mal vergessen einen rückgabewert auszuwerten? das ergebnis ist fast das gleiche: meistens ein absturz.
Ja, habe ich. Und nicht nur ich sondern genügend andere auch. Und ich behaupte in mehr als der Hälfte der Fälle (Ich tendiere meiner Erfahrung nach eher gegen 90%) gab es anschließend kein Absturz, sondern einen schwer zu findenden Fehler, Datenverlust...
fricky schrieb:
ich will z.b. manchmal auf exceptions reagieren, weil es 'ne möglichkeit gibt was zu retten. ich finde es ganz praktisch wenn mir ein compiler sagt: 'hey, hier könnte das und das schief laufen, also mach was dagegen oder wirf die exception weiter'.
Und das kann man (wie schon mehrfach beschrieben) nicht durch checked_exceptions, da sie garnicht in C++ implementierbar sind ohne die Sprache stark einzuschränken, oder merklich zu erweitern. Ganz davon abgesehen bin ich ein gegner davon Code mit Exceptionhandling zum durchreichen unleserlicher zu machen, wenn ich mich bewusst dagegen entscheide ihn an dieser Stelle behandeln zu wollen.
cu André
-
fricky schrieb:
tfa schrieb:
fricky schrieb:
blöd finde ich programmiersprachen, mit der man exceptions stillschweigend ignorieren kann. solche exceptions sind kein bisschen besser, als simple rückgabewerte.
Welche Sprache findest du dann nicht blöd?
z.b. auch solche, die exceptions überhaupt nicht kennen. entweder man machts gleich richtig, oder man lässt's bleiben.
Was ist denn jetzt richtig? Nur checked Exception und nichts sonst?
ich will z.b. manchmal auf exceptions reagieren, weil es 'ne möglichkeit gibt was zu retten. ich finde es ganz praktisch wenn mir ein compiler sagt: 'hey, hier könnte das und das schief laufen, also mach was dagegen oder wirf die exception weiter'. das trägt einiges dazu bei, stabilen code zu schreiben.
ganz doof ist es, wenn's vom compiler nicht die geringste warnung gibt und man für jede funktion in die doku schauen muss, um herauszufinden, ob überhaupt und welche exceptions denn nun generiert werden.
Die meisten Exceptions können eben nicht sinnvoll behandelt werden und müssen sowieso durchgereicht werden. Der Compiler (bzw. der Entwickler der API, die die checked Exception wirft) weiß auch nicht, ob du sie behandeln kannst. Warum sollte er dich also zwingen, dies zu tun? Die paar Fälle, wo ein Behandeln angebracht ist, musst du eben selbst herausfinden. Durch ausreichend Unittests sollte es auch möglich sein, zu verhindern, dass einem Exceptions durch die Lappen gehen.
Der Zwang führt nur dazu, dass der Entwickler die Exception eben ganz auffängt bzw. verschluckt. Wenn man Glück hat, wird der Fehler geloggt oder wenigstens auf stderr ausgegeben. Nach meiner Erfahrung trägt das überhaupt nicht zu stabilerem Code bei - ganz im Gegenteil.
Vor kurzem gab es die gleiche Diskussion übrigens auch im Java-Forum.