Hi Oliver,
um meine Meinung besser vertreten zu können müssen wir erstmal unsere Diskussions-Grundlage definieren.
Ich betrachte Exceptions und Schutzblöcke erstmal aus rein syntaktischer Sichtweise,also unabhänig von C/C++ oder den Hardware Exceptions in den Intel CPU's.
Zitat:
Zitat:
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)
Ob try finallys in C existieren oder nicht ist in dieser Diskussion irrelevant. Wichtig ist der Zusammenhang für mich das eine
Exception die Fregabe von allozierten Resourcen unterbrechen kann und ergo so eine Notwendigkeit für try finally Schutzblöcke existiert. Und wenn du genauer in C reinschaust so schützt wird das Garbage Collection ebenfalls durch unsichtbare Schutzblöcke vor Exceptions geschützt.
Zitat:
Zitat:
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.
Gewagte These
Warum sollte in der
OOP nur mit Methoden gearbeitet werden ? Im gegenteil wenn die
OOP eine Weiterentwicklung der proceduralen Programmierung darstellt so sollte die
OOP alle wichtigen Funktionalitäten davon auch erben. Ergo: Funmktions-Methoden mit Rückgabewerten sind ein fester Bestandteil der
OOP.
Mein Argumentation basiert auf der Idee der Abstraktions-Ebenen innerhalb eines Programmes. Es gibt Funktionale Bereiche in der Sofwtare die auch heute noch procedural programmiert sind, siehe die
RTL eines Delphi programmes. Dann gibt es andere Bereiche wie die
VCL, deren unterteilung in reine
OOP Überbaue und deren interne Zugriffe auf ordinäre Windows
API procedurale Schnittstellen.
Das
Exception Handling muß sich hier nun auf sinnvolle Weise integrieren. Und damit kommen wir zu dem Punkt das man in
RTL Funktionen zb. mit Rückgabewerten statt Exceptions arbeiten sollte. Das ist meine ganz persönlich Erfahrung, wohlgemerkt.
Zitat:
Zitat:
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).
Nein sehe ich nicht so, ganz im Gegenteil ->
OOP kann mehr als procedurale Programmierung und Exceptions können mehr als EXIT's. Exceptions sollten
OOP konform sein und sind in fact eine Notwendigkeit in der
OOP.
Somit unterstützt deine Gegenbehauptung nur meine ursprüngliche Aussage
Denn du hast Recht damit das
Exception viel mehr können als das was in reine proceduraler Programmierung machbar ist, das bestereite ich garnicht sondern bestätige es durch meine Aussage.
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:
Zitat:
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:
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!
Nein, wir reden über Excpetions, das sind meiner Meinung nach Erfindungen der
OOP. Als Konzept an sich wohlgemerkt.
Zitat:
Zitat:
Exceptions sollten nach Möglichkeit nur zur Fehlerbehandlung benutzt werden, AUCH wenn man reine Ausnahmebedinungen damit realisieren könnte.
... ist das dein Ernst?
Jain
Ja im Sine von Erfahrungen die ich gemacht habe das viele Programmierer das
Exception Konzept viel zu eng sehen. Sie sehen es ausschließlich als Fehlerbehandlung.
Nein im Sinne von den konzeptionellen Möglichkeiten die Exceptions bieten, da gebe ich dir absolut Recht.
Nur ! was ist das Ziel eines guten Source ? Die Wiederverwendbarkeit und Wartbarkeit durch andere Programmierer.Wenn ich nun ein bischen "intelligenter" programmiere andere aber weniger "intelligent" eben einseitig Exceptions begreifen, WER von beiden sollte besser in der Lage sein seinen eigenen Stilso anzupassen das alle Programmierer den Source verstehen ? ich meine das der "intelligentere" Programmierer anpassen sollte. Und exakt so ist meine Aussage zu verstehen: um häufige Missverständnisse im
Exception handlingzu vermeiden sollte man diese nach Möglichkeit wirklich nur zur Fehlerbehandlung benutzen, rein als willkürliche Festlegung.
Zitat:
Zitat:
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.
Nein werfe ich nicht ! Es ist eine andere Art & Weise die Dinge zu betrachten. Nun,
OOP ist eine Form der prozeduralen Programmierung, ohne deren Gundlagen gäbe es keine
OOP. Das dürfte Fakt sein. Beides sind willkürliche durch Menschen getroffene Entscheidungen über die Art & Weise wie WIR programmieren sollten. Das Instrument zur Durchsetzung dieser Entscheidungen ist das Werkzeug == Programmiersprache.
Wenn aber die
OOP nur eine andere Form des prozeduralen Konzeptes ist, dann ist die
OOP nur eine Fortführung der guten Eigenschaften der prozeduralen Mittel der Programmierung. Man darf und kann beides nicht voneinander trennen. Und mal ehrlich, gerade du müsstest wissen wie Objekte/Klassen in Delphi wirklich funktionieren und du weist auch das man mit rein prozeduraler Programmierung in PASCAL auf jedem Record + Proceduren die Funktionaliät der
OOP nachbilden kann. Das Einzigste was dann fehlt ist die erweiterte Unterstützung des Programmieres duch den Compiler selber.
Gruß Hagen