Zitat von
Luckie:
Wo liegt konkret der Vorteil von Exceptions? Oder anders gefragt, wann ist das werfen von Exceptions sinnvoll?
Exceptions sind eine coole Sache, weil du sie auf jeder beliebigen Ebene deines Programms filtern kannst. Wer behauptet denn, daß du unbedingt innerhalb *einer jeden* Funktion filtern mußt? Laß die
Exception doch durchschlagen bis zu jenem Handler, wo du sie haben willst ...
Ich denke mal in Delphi ist es auch nicht anders als in C++, wenn eine
Exception innerhalb eines Objektes geworfen wird, so kümmert sich der Laufzeitcode ums Aufräumen. Gleiches gilt auch bei einfachen Funktionen (dank Stack-Unwind). Wie man sehen kann, gibt es doch so einige Sachen wo Exceptions sinnvoll sind. Übrigens, nur weil man bestimmte Sachen auch mit True/False lösen kann, heißt es nicht, daß dies immer effektiv wäre. Eine
Exception erlaubt dir zB den Code für deine Fehlerbehandlung zu zentralisieren. Das würdest du sonst nicht erreichen können. Warum? Weil im Prinzip nach jeder IF-Abfrage auch ein Fehlerbehandlungsaufruf kommen
sollte.
Zitat von
dizzy:
Wenn man aber sauber programmiert, dann kann man sich doch aber den ganzen (wie ich finde schwachsinnigen) Overhead sparen, gell!?
OOP hin oder her... FEHLER
müssen doch nicht unbedingt AUCH Objekte sein
Müssen sie nicht. In C++ könntest du Zahlen, Referenzen, Pointer oder eben ganze Objekte werfen. Erst in letzterem Fall mußt du mit Overhead leben, weil nur dann das komplette Objekt kopiert wird.
Zitat von
dizzy:
Finde Exceptions im wesentlichen genau so birnig wie das Geheimnisprinzip. Was soll ich erst einen Methodcall auslösen, wenn ich doch DIREKT und SCHNELL zugreifen könnte!?
Tja, nehmen wir mal 2 Beispiele:
- Eine Punktklasse, deren 2 Properties X und Y public sind
- Eine Stringklasse
Jetzt darfst du entscheiden, wann das Geheimnisprinzip angebracht ist und wann nicht. Der Punkt ist nämlich folgender: dieses Prinzip existiert, damit sich der NUTZER einer Klasse keine Gedanken darüber machen muß, wie der PROGRAMMIERER es implementiert hat.
Zitat von
c113plpbr:
So hat man zwar ne if-Abfrage mehr, aber man könnte so mehrere konvertierungen zusammennehmen, und dann checken, ob es irgendwo nen fehler gab.
Naja und dann noch einen weiteren Parameter auf dem Stack usw. usf.
Wie mir scheint, hast du an noch keinem wirklich großen Projekt gearbeitet, weil du sonst Exceptions zu schätzen wüßtest.
Zitat von
negaH:
[...] Diese
Exception ist eine reine Ausnahme und kein Fehler. Logisch gesehen also absolut korrekt aber für viele Programmierer eher unlogisch im Programablauf.
Dann haben diese Programmierer nicht intensiv genug ihre Materie gelernt. Exceptions sind
das Vielzweckwerkzeug schlechthin. Windows benutzt sie unter anderem um den Stack "automagisch" zu vergrößern. Dieses Prinzip läßt sich auf viele andere Anwendungsfälle erweitern. Bspw. die Stringklasse, die automatisch die Pufferlänge anpaßt, wenn ein zu langer String eine
Exception auslöst (zB bei einer Zuweisung).
Zitat von
negaH:
Konkret heist dies, arbeitet man mit Exceptions so muß man auch mit try finally's arbeiten. Da ein Coder der auf fremden Code aufbaut nie wissen kann ob Exceptions ausgelösst werden, muß der Coder nun immer mit try finally's arbeiten.
Sehe ich nicht so. DENN: das try-finally-Konzept gibt es in C++ nicht. Und dort sind Exceptions nun wirklich usus! Es ist ein sehr spezifisches Konzept. (Und ja, es gibt einige C-Compiler, welche TRY-FINALLY implementieren)
Zitat von
negaH:
Hat man nun die Konsequenzen des
Exception Handlings verstanden so erkennt man sehr schnell das die generelle Anwendung von Exceptions in allen Funktionen zu einer Idiotie ausarten kann.
Entweder wir reden von
OOP, wo es konsequenterweise keine Funktionen sondern nur Methoden geben sollte, oder ich verstehe irgendwas an deiner Argumentation nicht.
Zitat von
negaH:
Im Grunde sind Exceptions nichts anderes als Harte Exits mit einem aussagekräftigem Grund für den Exit.
Wenn EXIT die Antwort und technische Krücke der Prozeduralen Programmierung ist, dann sind die
Exception die Antwort auf diese EXIT's aus Sicht der
OOP.
Gewagte These! Denn Exceptions können bekanntlich viel mehr (automagische Zerstörung des auslösenden Objekts, wenn nicht abgefangen usw).
Zitat von
negaH:
Exception's nur in High-Level Funktionen benutzen, die die Programflußebene darstellen die durch die
GUI Events aufgerufen werden.
Reden wir hier wirklich von
OOP?
Zitat von
negaH:
Exceptions NIEMALS in Release-Funktionen benutzen. Sprich Funktionen die Objecte oder Daten freigeben sollten keine Exceptions auslössen.
Dies stört mich am meisten an Delphi und seinen Klassen. Man muß sie manuell freigeben - immer!
Zitat von
negaH:
try except Blöcke immer mit bedacht und sparsam einsetzen. Ein vollständiges Abklemmen aller Exceptions per try except Block ist fast immer schlecht aus Sicht der Wartung des Programmes.
Ja eben, sage ich doch. Ruhig mal durchschlagen lassen das Teil.
Zitat von
negaH:
Exceptions sollten nach Möglichkeit nur zur Fehlerbehandlung benutzt werden, AUCH wenn man reine Ausnahmebedinungen damit realisieren könnte.
... ist das dein Ernst?
Zitat von
negaH:
Exceptions sind also KEIN Ersatz für Funktionen und deren Rückgabe-Werte. Exceptions sind hier vergleichbar mit der Möglichkeit ALLES Objectorientiert und basierend auf Kompoenenten zu codieren, auch wenn eine kleine Funktion ausreichen würde. Auch die
OOP und Komponenten sind KEIN Ersatz der prozeduralen Programmierung.
Hoppala, da wirfst du aber jahrelange Erkenntnisse mit ein paar abgeschmackten Phrasen über den Haufen.
Zitat von
negaH:
Exceptions also NUR auslösen wenn eine Bedingung eintritt in der der Programfluß KEINESFALLS fortsetzbar ist.
... Watt? Das hätte ich nun nicht von dir erwartet. Damit wirfst du die besten Teile von Exceptions schonmal auf den Müll.