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.
d) ein vernünftiger und portabler weg für unicode streams.
-
Optimizer schrieb:
Aber du hast schon verstanden, dass das Framework vom konkreten DBS abstrahieren soll, oder? Es macht dann wohl kaum Sinn, eine "Windows Anmeldung nicht erfolgreich wegen Domain-Problem xyz"-Exception durchzureichen. Das ist ohnehin für die Anwendung nicht verwertbar, die gerade einen Datensatz anfordern wollte.
Das ist deine Definition. Es wäre aber durchaus auch denkbar dass das framework diese arbeit eben nicht macht und fehler durchreicht.
gerade im oo design kommt es so oft vor dass du auf daten und objekten operierst die du nicht kennst, die dir auch egal sind. wenn ich sage waldi.gib_laut() und der waldi kann nicht laut geben ist es mir total egal warum er es nicht kann. deshalb bin ich hier exception neutral und reiche die exception schön sauber durch.
checked exception verlangen dass ich mich lokal damit auseinandersetze - ob ich es will oder nicht. und genau das ist der punkt. deshalb auch die studie von microsoft zu checked exceptions in c#:
Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result -- decreased productivity and little or no increase in code quality.
checked exception tauschen einen satz von problemen gegen einen anderen satz an problemen. sie lösen deshalb probleme nicht wirklich, man verschiebt sie nur. ich denke niemand hat etwas gegen die idee - aber versioning ist eben mit checked exceptions ein problem. das ist nicht kurzsichtig gedacht sondern es liegt daran dass mir der typ der exception einfach total egal ist. in 99% der fälle will ich wissen: fehler oder nicht fehler. und genau das machen checked exception schwerer (aber eben auch by design).
die ganze idee hinter checked exception ist es exception handling anstrengend zu machen. der vorteil liegt auf der hand: man wird zum behandeln von fehlern gezwungen. der nachteil ist aber: man wird zum behandeln von fehlern gezwungen
-
Shade Of Mine schrieb:
die ganze idee hinter checked exception ist es exception handling anstrengend zu machen. der vorteil liegt auf der hand: man wird zum behandeln von fehlern gezwungen. der nachteil ist aber: man wird zum behandeln von fehlern gezwungen
ne, man soll exceptions zur kenntnis nehmen. das ist ein wichtiger unterschied. wenn man eine exception nicht behandeln will, oder kann, listet man sie z.b. im throws-statement im funtionskopf auf und ist sie damit los. blöd finde ich programmiersprachen, mit der man exceptions stillschweigend ignorieren kann. solche exceptions sind kein bisschen besser, als simple rückgabewerte.
-
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. Außerdem: Du findest es also doof, dass Java neben den Checked Exceptions auch Unchecked Exceptions kennt?
-
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? Checked Exception gibt es (was bedeutende Programmiersprachen angeht) nur in Java. Selbst in C# wurden sie niucht eingeführt. Es war halt ein Experiment, aber die Erfahrung zeigt, dass checked Exeptions eher Probleme schaffen als lösen.
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?
-
Wann kann man den schon sinnvoll was mit Exceptions anfangen was man dann dem User mitteilen kann? Das Problem an den Java checked Exceptions ist doch, dass es zuviele gibt mit denen man eigentlich nix sinnvolles machen kann. Bei IOExceptions kann man das dem User anzeigen, dass er dann z.B. ne andere Datei wählen kann. Aber wieso sind NoSuchFieldException, ClassNotFoundException, AlreadyBoundException, CloneNotSupportedException, UnsupportedCallbackException, AWTException usw. checked? Was soll der User da groß machen? Das ist doch fast immer ein Grund das Programm zu beenden, weil irgendwas exterm schief gelaufen ist.
-
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.