fat-lobyte hat geschrieben:Du sagst, es gibt keine Beispiele, die die Verwendung von Exceptions rechtfertigen würden.
Auch hier werde ich jetzt Klartext sprechen, auch wenn das vielleicht unhöflich klingt.
Es macht überhaupt keinen Spaß, zu diskutieren, wenn ich genauso gut mit einer Wand reden könnte. Ich kann verstehen, dass schwer greifbare Dinge unverstanden bleiben, wie die Schwierigkeiten, Exceptions am richtigen Punkt abzufangen, dafür muss man sich mal eben ein komplexes Beispiel-Programm aufbauen, was die meisten hier vermutlich nie geschrieben haben.
Ich kann wohl nicht davon ausgehen, dass meine Argumentation nachvollzogen wird, wenn selbst greifbare Dinge wie:
Xin hat geschrieben:Nochmals: Ich bin nicht gegen Exceptions, aber ich bin absolut gegen die Verwendung von Exceptions als Regel. Dass Dateien nicht gefunden werden ist keine Ausnahme.
oder
Xin hat geschrieben:Ich kann gute Beispiele für Exceptions konstruieren, aber ich habe noch nie jemanden gesehen, der ein gutes Beispiel konstruierte und gleichzeitig für Exceptions war. Wer gute Beispiele konstruiert, weiß, dass sie Exceptions dafür nicht verwendet werden.
Ein Programm, dass über mehr als 5 Ausnahmen verfügt missbraucht Exceptions. Und eigentlich denke ich, dass 2 schon über die obere Grenze hinausgeht.
Jetzt kommt von Dir der Spruch 'Du sagst, es gibt keine Beispiele, die die Verwendung von Exceptions rechtfertigen würden.', ich soll also gegen Dinge argumentieren, die überhaupt nicht Teil meiner Argumentation sind. Du schiebst mir hier Sachen unter, gegen die Du dann argumentierst? Wenn auf meine Argumentation nicht eingegangen wird, brauche ich sie auch nicht aufzuschreiben.
fat-lobyte hat geschrieben:Sieh dir diesen Code an, und sag mir dass das hier etwas anderes ist als "throw NameDerFirmaException(errstr)".
Es ist aus der Datei "malloc.c", aus der glibc 2.7, die so ziemlich jeder mit aktuellem GNU/Linux system verwendet:
...
Es ist C- code, also keine Exceptions. Ich habe die 'errstr = "double free or corruption"; goto errout;' nicht gezählt, aber ich denke es ist klar dass genug drinnen sind.
Was findest du besser in diesem Fall? Exceptions zu verwenden? Oder goto ?
Goto finde ich hier angebracht, die Position des Labels empfinde ich hier als schlecht.
Das ist eine absolute Low-Level-Funktion und das bedeutet, dass es absolut egal ist, wie die Funktion aussieht, hier ist die erste Priorität Geschindigkeit um absolut jeden Preis. Es muss garantiert funktionieren, aber es ist absolut legitim, dass man sich in so eine Funktion einen ganzen Tag einarbeiten muss, wenn sie dafür ein paar Takte Rechenzeit spart.
Zwei Dinge:
1) Du bringst mir hier einen Code, der ein Goto enthält, weil ich throw mit Goto vergleiche. Ich vergleiche Throw nicht mit einem Goto, das sich innerhalb einer Funktion bewegt, also überschaubar ist, sondern dass quer durch den Code springt. Bitte lies, was ich schreibe und wenn Du es nicht verstehst, dann frag nach. Aber Du interpretierst hier unreflektiert Dinge hinein, die ich so nicht beschrieben habe.
Xin hat geschrieben:Und nicht zu vergessen, ein throw ist ein Goto nach irgendwo, denn man weiß nicht, wo man letztendlich gefangen wird und wie fähig das jeweilige catch ist.
Dieser Code enthält ein lokales Goto, sehr leicht nachzuvollziehen. throw springt über Dateien und Namensräume hinweg zu einem Ziel, dass ich bei throw nichtmals kenne.
Das kann Goto auch, darum ist es (zu Recht) verschrieen. Ein goto innerhalb einer Funktion ist aber diskutabel. Nach Möglichkeit ist es zu vermeiden und die Möglichkeit ist fast immer gegeben. Aber man kann dadrüber diskutieren.
2) Wollt ihr mir jetzt laufend Codes vorwerfen, bis ihr das Beispiel gefunden habt, bei dem ich Exceptions als gute Möglichkeit ansehe und mir anschließend mit einem Spruch wie 'Du sagst, es gibt keine Beispiele, die die Verwendung von Exceptions rechtfertigen würden.' zu erklären, dass ich ja grade meine Überzeugung widerlegt habe?
fat-lobyte hat geschrieben:Oder würdest du vielleicht lieber das ganze komplett umschreiben, und "den status des algorithmus zu jederzeit wissen", und angemessen auf Fehler reagieren? Ich bin mir sicher, die glibc- Entwickler freuen sich auf deine Patches.
Ich würde das goto tatsächlich rausnehmen und
Code: Alles auswählen
errstr = "free(): invalid pointer";
malloc_printerr (check_action, errstr, mem);
return;
als Macro anpassen. Das würde die Funktion geringfügig beschleunigen, aber auch geringfügig vergrößern. malloc stammt noch aus einer Zeit, in der Kernel möglichst klein sein sollte, damit er auf Maschinen lief, die soviel Speicher haben, wie der Kernel heute Speicher verbraucht.
fat-lobyte hat geschrieben:Ich sags dir ganz ehrlich, anstatt solche goto's zu schreiben werfe ich lieber eine exception, die im übergeordneten frame aufgeräumt wird.
Dieses Goto hat nichts mit mit einem throw zu tun.
Das Goto ist in der Funktion unangebracht und problemlos zu entfernen.
Eine Exception ist in der Funktion absolut unangebracht, wie Exceptions grundsätzlich in Low-Level-Funktionen unangebracht sind.
Ich gehe noch einen Schritt weiter: In Lowlevel Funktionen ist jegliche Fehlerbehandlung unangebracht, beispiel sqrt. Bereichne ich sqrt( -1 ), dann habe ich kein Problem damit, wenn ich ein falsches Ergebnis bekomme. Das ist nicht der Fehler von sqrt(), sondern der Fehler des Programmierers, der sqrt aufruft. Low-Level-Funktionen haben eine Aufgabe in einem wohldefinierten Parameterbereich und die Aufgabe haben sie so schnell wie nur irgendmöglich erledigen.
Asserts helfen dem Entwickler während der Entwicklung dafür zu sorgen, dass der Programmierer sich ausschließlich in dem Bereich bewegt, aber als Produktivsystem, will ich hier Dampf sehen und keine Funktionen, die mit angezogener Handbremse unterwegs sind.
Wer Programmiert, sollte wissen, was er tut und in welchem Bereich er sich bewegt. Wer als Entwickler an die Hand genommen werden muss, darf sich nur in Bereichen bewegen, wo die Lib ihn an die Hand nimmt. Willkommen bei Java und .NET, aber so ein Programmierer möge sich bitte nicht in C++ bewegen.
Wer Programmiert, sollte wissen, was er tut und in welchem Bereich er sich bewegt. Wer als Entwickler an die Hand genommen werden muss, darf sich nur in Bereichen bewegen, wo die Lib ihn an die Hand nimmt. Willkommen bei Java und .NET, aber so ein Programmierer möge sich bitte nicht in C++ bewegen.
Wer Mathematik betreibt, sollte verstehen, dass Computer-Mathematik nicht der Schul-Mathematik entspricht. Wenn er dann die Schulmathematik nicht beherrscht und nicht weiß, dass die Wurzel aus negativen Zahlen eine komplexer Wert wird, also double sqrt( double ) für negative Werte nicht gehen kann... ich bin dafür, dass eine Sprache den Entwickler maximal unterstützt, aber ich setze an den Entwickler Grundvoraussetzungen. sqrt(), wie auch malloc() sollten ein assert enthalten, dass die Erwartung ausdrückt, dass eine positve Zahl verlangt wird. Ansonsten erwarte ich, dass ein Entwickler seine Algorithmen so formuliert, dass ein assert niemals anspricht.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.