Codingstyle?
-
übrigens schrieb:
Konrad Rudolph schrieb:
übrigens schrieb:
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.
Und da kannst du doch nicht behaupten, dass das dasselbe ist.
Für solche Fälle eignet sich ein Proxy, sagte ich doch bereits.
Und was macht der Proxy anders als ein try catch(...) um jeden Methodenaufruf?
Nichts. Na und? Dieser Proxy wird ja nur für Googles veralteten Code verwendet. Aber die Bibliotheken werden ja auch noch anderswo eingesetzt, und dort braucht man dann keinen Proxy und könnte eine vernünftige Ausnahmebehandlung verwenden, wenn die Coding Guidelines dies nicht verhindern würden.
-
übrigens schrieb:
wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.
Die Gründe sind eigentlich alle FUD.
-
Konrad Rudolph schrieb:
übrigens schrieb:
wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.
Nicht wirklich. Der Grund klingt erst mal gut, ist aber eigentlich Quatsch. Es stimmt zwar, dass es enorm viel Aufwand bedeutet, wenn man ein 'throw' in existierenden Code einfügt, weil tatsächlich alle aufrufenden Funktionen aktualisiert werden müssen.
Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“
Wenn Google ihren OpenSource-Code auch in internen, Ausnahme-freien Projekten verwenden wollen, müssen sie eben einen Wrapper bauen. Das ist übliche Praxis und ich weiß nicht, wieso hier dagegen argumentiert wird.
Returncodes kann man ignorieren, Exceptions nicht ...
-
i_like_it schrieb:
Returncodes kann man ignorieren, Exceptions nicht ...
und wie man das kann
-
sothis_ schrieb:
i_like_it schrieb:
Returncodes kann man ignorieren, Exceptions nicht ...
und wie man das kann
Spätestens beim ersten Aufruf bemerkt man es, ignorierte Returncodes findet man in der Regel wesentlich schwerer...
-
sothis_ schrieb:
i_like_it schrieb:
Returncodes kann man ignorieren, Exceptions nicht ...
und wie man das kann
klar kann man es, aber man muss zumindestens ein try{}catch(...){;} drum machen, bei Returncodes brauchst du gar nichts machen ... dahingehend war ignorieren gemeint, klar ist dass ich nicht auf Exceptions reagieren brauch und sie in einem leeren catch-Block fangen kann.
-
i_like_it schrieb:
sothis_ schrieb:
i_like_it schrieb:
Returncodes kann man ignorieren, Exceptions nicht ...
und wie man das kann
klar kann man es, aber man muss zumindestens ein try{}catch(...){;} drum machen, bei Returncodes brauchst du gar nichts machen ... dahingehend war ignorieren gemeint, klar ist dass ich nicht auf Exceptions reagieren brauch und sie in einem leeren catch-Block fangen kann.
arg, zu schnell abgesendet
Ja ich weiss man muss nicht einmal try-catch aussen drum machen, solange kein Fehler / Exception auftritt passiert auch nichts, aber wenn eine Exception auftritt gibt es wenigstens ein terminate(), bei Errorcodes läuft das Programm weiter...
-
das ist alles richtig, aber man kann es
-
sothis_ schrieb:
das ist alles richtig, aber man kann es
Du wiederholst dich.
-
Strolch schrieb:
sothis_ schrieb:
das ist alles richtig, aber man kann es
Du wiederholst dich.
wie meinen?
-
i_like_it schrieb:
..., bei Errorcodes läuft das Programm weiter...
Und das empfindest du als sinnvoll? Es tritt ein Fehler auf, vielleicht fataler Fehler und das Programm läuft dann unkontrolliert weiter? Im Extremfall formatiert es halt die Festplatte, aber immerhin, das Programm ist weitergelaufen.
Bei einem unbehandelten Fehler, sollte das Programm sofort zum halten gezwungen werden, das ist das einzig richtige. Wenn es weiterlaufen würde, könnt es Schaden verursachen. Deshalb sind die Exceptions auch so gut, weil sie genau dieses Verhalten hervorrufen.
Desweiteren ist es praktisch bei den Exceptions, dass der Fehler extrem leicht auf einer anderen Ebene behandelt werden kann. Das geht mit Returncodes nur sehr mühsam oder es erfordert Anpassungen der eigenen Funktion, an denen der API.
Grüssli
-
Dravere schrieb:
i_like_it schrieb:
..., bei Errorcodes läuft das Programm weiter...
Und das empfindest du als sinnvoll? Es tritt ein Fehler auf, vielleicht fataler Fehler und das Programm läuft dann unkontrolliert weiter? Im Extremfall formatiert es halt die Festplatte, aber immerhin, das Programm ist weitergelaufen.
Bei einem unbehandelten Fehler, sollte das Programm sofort zum halten gezwungen werden, das ist das einzig richtige. Wenn es weiterlaufen würde, könnt es Schaden verursachen. Deshalb sind die Exceptions auch so gut, weil sie genau dieses Verhalten hervorrufen.
Desweiteren ist es praktisch bei den Exceptions, dass der Fehler extrem leicht auf einer anderen Ebene behandelt werden kann. Das geht mit Returncodes nur sehr mühsam oder es erfordert Anpassungen der eigenen Funktion, an denen der API.
Grüssli
das habe ich nicht behauptet
ich bevorzuge selbst Exceptions, statt diesem krampfhaftenrv = irgendEineFunktion(); if(rv != RV_OK){...}siehe auch:
i_like_it schrieb:
Returncodes kann man ignorieren, Exceptions nicht ...
-
Hmmm, irgendwie habe ich was falsches gelesen oder unregistrierte haben seit neustem die Möglichkeit ihre Beiträge zu editieren. Wenn ich meine aktuelle Verfassung mit einbeziehe, dann wohl eher ersteres ... *hatte noch keinen Kaffee*
Grüssli
