Codingstyle?
-
Konrad Rudolph schrieb:
übrigens schrieb:
Konrad Rudolph schrieb:
Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches
if (retval != SUCCESS) return FAILURE;wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes.
Ich schrieb doch gar nicht, dass man das „um jeden Methodenaufruf“ machen muss, aber *irgendwo* muss man es machen. Sonst bräuchte man ja auch bei Ausnahmen keine Ausnahmebehandlung zu schreiben, und genau das wird hier ja behauptet.
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?
-
Shade Of Mine schrieb:
Konrad Rudolph schrieb:
Moment mal. Den hast ja nun aber wirklich Du angefangen.
Ich habe dir lediglich die Wahrheit gesagt. Wenn dich das beleidigt, ist das nicht mein Problem.
Toni, bitte schau Dir Deinen ersten Kommentar auf meine Aussage nochmal an. Der klingt wirklich einfach nur kindisch (damit meine ich weniger das explizite „Ätsch“ als vielmehr die komische Unterstellung, ich würde Sprachmittel „falsch“ benutzen).
bestes beispiel hier waere python. manche lieben die syntax andere hassen sie. ergo: aesthetik ist subjektiv.
Wo ist da eine Argumentation? Das ist ein Problem bei Deinem gesamten Text: es fehlt einfach eine Argumentation.
Das ist weder ein Argument für noch gegen 'and', aber es ist ein Argument. Du hingegen argumentierst nicht sondern stellst nur lustig Behauptungen auf („wurde als schlecht befunden“).
Mach die Augen auf, schau dich um. Wer verwendet die iso646 Bezeichner? Sutter, Meyers, Alexandrescu, Coplien,...? Nein, niemand. Ich kenne genau eine Person die das tut: dich.
Ich kenne mehrere, aber das ist irrelevant. Dein argumentum ad verecundiam ist eine klassische Argumentationsschwäche, und die durchzieht Deinen gesamten Text. Und genau *das* ist Kindergarten. Ich versuche hier von Anfang an, eine Argumentation aufzubauen, Du hingegen zappelst einfach nur mit Deinen Armen.
Nein, wieso sollten sie? Die Sprachen sind ja auch ansonsten in Punkto Lesbarkeit ein einziges Fehldesign. Und sowohl Gosling als auch Hejlsberg scheinen sowieso einige sehr kranke Ansichten zur Programmierung zu vertreten. Die beiden als Autorität auf diesem Gebiet anzusehen habe ich schon lange aufgegeben.
Muss man dann eigentlich noch weiter Diskutieren? Du stehst komplett alleine da mit deiner Meinung und zwar komplett. Ich kenne niemanden der auch nur aehnlich denkt.
Dann kennst Du eben nur einen sehr eingeschränkten Personenkreis. Dass ich mit dieser Meinung alleine stehen soll ist patenter Quatsch.
Vielleicht hast du natuerlich recht und alle anderen unrecht - das kann ich nicht beurteilen...
Es geht hier auch gar nicht um Recht oder Unrecht, sondern um eine saubere Argumentation. Immer noch.
uebrigens erkennt man wie wackelig du stehst daran, dass du das entscheidende argument komplett ignorierst: jeder kann hier heute und jetzt and statt && verwenden aber es macht niemand.
Lies doch mal, was ich schreibe. Ich habe das nicht ignoriert, sondern ich habe diese Argumentation bereits in meinem ersten Posting (bei Microsoft Connect) angesprochen und widerlegt.
das ist jetzt auch mein letzter post in dem thread, ich hoffe fuer dich dass du wenn du mal ruhiger bist es dir nochmal durch den kopf gehen laesst und einsiehst dass ich nichts bewertendes gesagt habe sondern nur fakten aufgezaehlt habe.
Sorry Tony, ich schätze Dich als C++-Mensch, aber mit Dir zu argumentieren ist wirklich unmöglich. Und das, was Du an „Fakten“ nennst, hat entweder nichts mit dem Thema zu tun oder ist eine Anekdote aus Deinem persönlichen Leben, die Du zu verallgemeinern versuchst.
Vielleicht nochmal ganz zum Schluss: Wenn ich Code für ein anderes Projekt schreibe, dann bin ich natürlich konsistent. Wenn andere Dort '&&' verwenden, dann tue ich das auch; alles andere wäre wirklich doof und ich glaube, darum gibt es auch gar keine Debatte. Aber das hat nichts mit dem Thema zu tun.
-
ü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
