Exception Handling.

[MathiasSimmack]

1. Wir sind immer noch beim Thema, denn

Zitat von c113plpbr:

irgendwann bin ich dann dazu übergegangen machen functions selbst zu schreiben, und keine 'Unhandled Exception' auszulösen, sondern die Fehlerbehandlung vor Ort durchzuführen.

was der Auslöser für mirages Posting war,

2. wird man doch noch mal fragen dürfen.

[negaH]

Leider findet man über das Exception-Handling tatsächlich nur wenig konzeptionelle Literatur.

Exceptions = Ausnahmen beziehen sich nicht ausschließlicher Weise nur auf eine Fehlerbehandlung. Dies zeigte besonders der Fall mit EConnectionClosedGracefully der Indy Komponenten. Diese Exception ist eine reine Ausnahme und kein Fehler. Logisch gesehen also absolut korrekt aber für viele Programmierer eher unlogisch im Programablauf. Denoch haben die Programmierer von Indy exakt richtig gehandelt wenn man das Verhalten und die Auswirkungen einer Exception betrachtet.

Die wichtigste Auswirkung einer Exception ist das sofortige Abbrechen der auslösenden Funktion und sogar der übergeordneten aufrufenden Funktionen. In den meisten VCL basierten Programmen springt der Programablauf bis zum obersten Message-Handler. Diese Wirkweise ist eine Wirkung mit sehr harten Konsequenzen im Programablauf und bedingt auch die Schaffung von technischen Maßnahmen bestimmte Codebereich denoch ausführen zu lassen. Somit kommt man sofort und logischersweise von der Möglichkeit Exceptions auslösen zu können, zu der Notwendigkeit mit try finally Blöcken diese Logik kanalisieren zu können. 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.

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. Man muß also die gute Balance finden in wie weit man Exceptions anwendet, sprich die Verhältnissmäßigkeit der Wahl der Mittel. Dazu kann man einige Pi*Daumen Regeln anwenden:

Man teilt den Programfluß dreistufig in einfache Lowlevel Funktionen, komplexere Highlevel Funktionen und GUI Funktionen auf. Normalerweise rufen GUI Funktionen wie Events, Messages nur die komplexeren Highlevel Funktionen auf. Diese wiederum die Lowlevel Funktionen. Nun, die Lowlevel Funktionen sollten Exception-frei sein, ausgenommen es werden deren Parameter überprüft (wo aber Assertions besser geeignet wären). Die High-Level Funktionen sollten mit Exceptions arbeiten da deren Programmierung von aussagekräftigen Funktionsrückgabewerten viel zu kompliziert werden kann. D.h. die Exceptions würden innerhalb dieser Highlevel Funktionen deren Aufbau wesentlich erleichtern. Die Programmierung von Rückgabewerten, wie zB. HResult bei Interfaces ist dagegen viel viel mehr Code Overhead und erhöht den Aufwand in der Codierung im Vergleich zu Exceptions.

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.

Soweit so klar. Das was nun das Auslösen von Exceptions so kompliziert macht ist deren gezielte Abarbeitung, d.h. also die Anwendung von try except end Blöcken. Die Sinnhaftigkeit von Exception bleibt nur gewahrt wenn man nicht permanent in High/Lowlevel Funktionen leere try except Blöcke codiert. D.h. die Anwendung von try except Blöcken sollte ganz genau überlegt werden und wenn angewendet dann müssen sie ganz gezielt nur auf einige Exception Typen reagieren. WARUM ?? Das Ziel des Exceptions Handlings sollte es sein für den Programmierer aussagekräftige Ausnahmebedingung vom normalen Programmfluß zu visualisieren. Werden die try except Blöcke unüberlegt angewendet so heist dies das man dieses Ziel nicht erreichen kann, der Vorteil der Exceptions geht also verloren !!

Also in kurz:

Exception's nur in High-Level Funktionen benutzen, die die Programflußebene darstellen die durch die GUI Events aufgerufen werden.

Exceptions in Lowlevel Funktionen, wie zB. StrToInt() sind im Grunde eher störend und sollten generell vermieden werden. Im Falle von StrToInt() könnte man argumentieren das es die Highlevel Schnittstelle zu TryStrToInt() oder StrToIntDef() darstellt. Dies ist insofern richtig wenn man StrToInt() innerhalb von GUI Events betrachtet. Da StrToInt() aber eine Funktion der RTL ist würde ich eher meinen das es eine LowLevel Funktion darstellt und eigentlich KEINE Exception auslösen sollte.

Exceptions NIEMALS in Release-Funktionen benutzen. Sprich Funktionen die Objecte oder Daten freigeben sollten keine Exceptions auslössen. Dies liegt daran das solche Funktionen meistens gruppiert in übergeordenten Funktionen auftreten. Würde eine Exception ausgelösst so bedeutete dies das nachfolgende Release-Funtionen Speicherleaks produzieren würden. Technologisch müsste der anwendende Coder nun JEDEN Aufruf solcher Release-Funktionen per separatem try finally schützen. Es ensteht eine Sinnlosigkeit der Exceptions in diesem Falle.

Exception dagegen in Allocator-Funktionen, sprich Constructoren, verwenden. Die Exceptions verhindern somit die weitere Allokation von sinnlosen Speicherbereichen.

Code immer schützen mit try finally end Blöcken, egal ob mit oder ohne Exceptions gearbeitet wird.

try finally Blöcke werden IMMER ausgeführt wenn sie als ÄUSSERTER Block verwendet werden. Demzufolge sollten try finally Blöcke zu-äusserst stehen

In fast allen Fällen reicht EIN einzigster try finally Block pro Funktion aus. Zb. so

Delphi-Quellcode:

var
  S,D: TStream;
begin
  S := nil;
  D := nil;
  try
    S := TFileStream.Create(...);
    D := TFileStream.Create(...);
   .....
  finally
    S.Free;
    D.Free;
  end;
end;

Hier sieht man das man immer mit einem try finally auskommen kann.

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.

Exceptions sollten nach Möglichkeit nur zur Fehlerbehandlung benutzt werden, AUCH wenn man reine Ausnahmebedinungen damit realisieren könnte. Diese Regel dient zur Vorbeugung von Mißverständnissen durch andere Programmierer. Bestes Beispiel ist die häufigste Frage von INDY Anwendern, was "Connection closed gracefully" denn für ein Fehler ist ?!

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.

Das hinterhältige an Exceptions ist deren Fähigkeit das Black-Box-Prinzip der prozeduralen Programmierung zu zerstören !!

Exceptions also NUR auslösen wenn eine Bedingung eintritt in der der Programfluß KEINESFALLS fortsetzbar ist.

Gruß Hagen

[Luckie]

Super. Danke.

Zitat von Hagen:

Demzufolge sollten try finally Blöcke zu-äusserst stehen

Bei der korrigierten Version meines ersten Codes ist das nicht dr Fall, wesewegen ich auch gefragt habe, ob der Stream auch wieder freigegeben wird, wenn WriteBuffer eine Exception auslöst.

[negaH]

Achso, das spielt aber in dem Fall keine große Rolle. Ich habe es nur deshalb so gemacht weil ja Stream.Free im finally end; Block ebenfalls eine Exception auslösen könnte. Der äussere try except Block fängt also auch diese Ausnahme dann ab. Da der try except Block alle Excetions abfängt und nicht mit raise weiterleitet, ist es besser so vorzugehen. Es trifft der Spruch zu "Ausnahmen bestätigen die Regel". D.h. in diesem Falle, wo gleich nach dem try finally der except end Block kommt finde ich es besser so herum.

Mann, ist schwierig zu erklären wenn man solche Sachen nur einmalig vor Jahren durchdacht hat und nun nur noch rein gefühlsmäßig es als richtiger empfindet, du weist ja was ich meine Manche Sache verstehe ich halt aus dem Bauch heraus einfacher als sie dann einem anderen logisch richtig zu erklären.

Gruß Hagen

[Olli]

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.

[negaH]

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

[Olli]

Moin Hagen,

Zitat von negaH:

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.

Oki.

Zitat von negaH:

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.

Methoden sind ja noch Funktionen, aber eben Funktionen von Objekten (oder abstrakter, von Klassen). Die Erbfolge ist also durchaus eingehalten.

Zitat von negaH:

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.

Verstehe ich. Aber genau an dieser Stelle finde ich die obige Diskussion etwas verworren, weil ständig die Konzepte von OOP und prozeduraler Programmierung (nicht nur von dir!) durcheinandergeworfen werden.

Zitat von negaH:

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.

Bei RTL-Funktionen hast du ja sowieso keine Wahl. Bei Zugriff auf die Win32-API ebenfalls nicht. Aber dennoch kann man ja all das kapseln (VCL und MFC sowie WinForms sind der beste Beweis dafür).

Zitat von negaH:

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.

Ja, du beschränkst aber dogmatisch die Einsatzgebiete für Exceptions auf "Fehler signalisieren" - so verstehe ich deine obige Aussage. Daher mein Einwand. Denn Exceptions können weit mehr.

Zitat von negaH:

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.

... du hast zuviel Schopenhauer gelesen

Zitat von negaH:

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.

Puh, ich dachte schon ...

Zitat von negaH:

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.

Na ich denke mal, daß man Wartbarkeit nicht primär darauf ausrichten sollte, daß ein anderer Programmierer den Code warten kann, man selber reicht schon in der Betrachtung.
Du hast ja durchaus recht damit, daß es sein kann, daß jemand anderes nicht so smart ist, aber rechtfertigt das, den Code konzeptionell schlechter zu gestalten? Denn wenn ich OOP und prozedurale Programmierung schlecht verquicke, wird dies am Ende mehr Probleme machen.

Zitat von negaH:

Nun, OOP ist eine Form der prozeduralen Programmierung, ohne deren Gundlagen gäbe es keine OOP. Das dürfte Fakt sein.

Nein und Ja. Natürlich gäbe es ohne PP kein OOP, aber OOP ist - benutzen wir die Metapher der Vererbung - ein Kind der PP. Und nur weil du das Kind deiner Mutter bist, bist du nicht eine andere Mutter - der gemeinsame Nenner besteht darin, daß du als Mensch klassifiziert wirst.

Zitat von negaH:

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.

Wes Grundes? Man sollte sie sogar trennen um konsequent zu bleiben. Vorteil von OOP ist ja gerade nicht, daß der Laufzeitcode soviel optimierter ist als der von PP-Programmen (das macht eh der Compiler), sondern vielmehr die Wartbarkeit gesteigert wird, weil ein Bug in einer "Elternklasse" gefixt werden kann und die "Kindklasse" diesen Fix erbt. Das Ganze wird dann dank Geheimnisprinzip und Polymorphie noch scharf angerichtet und ist so ein sehr leckerer Mix für den Programmierer. Manche mögen's halt nur nicht scharf

Es ist richtig, daß man manchmal nicht umhinkommt Funktionen im alten Stil zu benutzen - ebenso finde ich es hirnrissig sowas wie Integer als Klassen zu betrachten (Java), aber im Gesamtkonzept sind auch dies Puzzlesteine, welche es erlauben weit komplexere Programme zu schreiben.

Zitat von negaH:

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.

Das ist richtig. Kann man in fast allen OOP-Sprachen (die ja meist von einer PP-Sprache abstammen) finden.

[negaH]

Ich mache es mal kurz weil wir uns in unserer Meinung nun doch stärker annähern. Ich bin aber pragmatisch und ein Praktiker ergo:

Zitat:

Na ich denke mal, daß man Wartbarkeit nicht primär darauf ausrichten sollte, daß ein anderer Programmierer den Code warten kann, man selber reicht schon in der Betrachtung.
Du hast ja durchaus recht damit, daß es sein kann, daß jemand anderes nicht so smart ist, aber rechtfertigt das, den Code konzeptionell schlechter zu gestalten? Denn wenn ich OOP und prozedurale Programmierung schlecht verquicke, wird dies am Ende mehr Probleme machen.

Ja man muß es sogar. Zwei wichtige "Beweise" führe ich an:

1.) ich rede von professioneller Arbeit wenn ich von programmieren rede, ergo gehört dazu Teamarbeit und Projekte die über längere Zeiträume von verschiedenen Leuten gepflegt werden müssen. In solchen Szenarien ist es unabdingbar das sich die Programmierer auf ein gemeinsammes Niveau verständigen, und das sollte im "allgemeinen Wissenstand" gehalten werden. Außnahmeprogrammierer müssen sich in solchen Teams zurücknehmen.

2.) wir schauen in die Geschichte der Computerei, und stellen fest das sich eben fast NIE das durchgesetzt hat was das Beste darstellte. Es setzte sich immer das durch was im allgmeinen Interesse rundum praktisch war. Also das was sich auch gut vermarkten lässt, was Profit bringen wird und denoch technisch einigermaßen gelungen war. Also nicht das was hypothetisch supergut war aber zb. keinerlei Lobby dahinter hatte.

Fazit: als Pragmatiker konzentriert man sich auf das Realistische und nimmt wohlweislich Kompromisse in kauf. Und nun aus Erfahrungswerten heraus in Delphi die Exceptions als reine fehlermeldungen zu betrachten halte ich in diesem Sinne als annehmbare Schwäche.
D.h. natürlich nicht das die Programmierer mit Wissensdefiziten mehr über Exceptions im Gesammtkontext lernen müssen.

Meine diesbezügliche Aussage war wie oben schon angedeutet nur ein Tipp von mir an andere Programmierer. Daran halten muß sich keiner, aber aus meiner Erfahrung heraus verhindert man so viele Mißverständnisse. Ich errinnere nur an die "EConnectionClosedGracefully" Exception in den INDY's. Zum zeitpunkt der Veröffentlichung waren sehr viele heise Diskussionen in den NewsGroups die sich exakt um die Frage drehten -> ist eine Exception nur ein Fehler oder eine Ausnahme die nicht zwangsläufig ein Fehler sein muß.
Man kann sich streiten, jahrhunderte lang, oder man wird in einer Firma einfach willkürlich eine Festlegung treffen. Und in unserer Firma heist diese "Exception = Fehler". (Ausnahmen bestätigen dann nur die Regel).

Gruß Hagen

[negaH]

Exception ansich sind ein sehr wichtiges Mittel der Programmierung geworden. Sie stellen sozusagen einen parallel zum eigentliche Programablauf feststehenden Programmablaufplan dar. Und exakt in dieser Parallelität sehe ich auch gleichzeitig die Schwäche der Exceptions. Denn im Denkvermögen der meisten Programmierer stellt sich ein Program am einfachsten als simple und rein sequientielle Steuerung dar. Exception widersprechen also unserem Denkvermögen, meistens zumindestens. Nun, das bedeutet das asynchron eintreffende Exceptions oder auch Events immer eine Denk-Hürde für die meisten Programmierer darstellen, ergo potentielle Fehlerquellen. Das schlimme daran ist es das diese Fehlerursachen meistens noch viel stärker Nachfolgefehler nach sich ziehen.

Meine Lösung aus diesem Dilema lauten:

1.) wenn Exception dann aber auch immer try finally benutzen um resourcen zu schützen, das verringert die Anzahl unerwünschter Nachfolgefehler falls eine Exception/Event asynchron den Programfluß unterbricht.

2.) Wissen, die Programmierer habe zu lernen wie asynchrone Programme per Exceptions/Events zu arbeiten haben

3.) Beschränkungen, durch willkürlich Beschränkungen auf gemeinsam benutzte und Firmeninterene Vorgaben im Arbeitsstil.

4.) das Eintreffen/Auslösen solche asynchrone Exceptions/Events möglichst reduzieren. Besonders eben in RTL/Helper Funktionen sollte man auf Exceptions verzichten und stattdessen über Rückgabewerte einen Fehler signalisieren. Nichts ist schlimmer wenn eine solche Funktion tief im Inneren eines Programmes ständig Exceptions auslösst. Das führt dann dazu das der Programmierer wie wild alle möglichen Exception abfängt und somit den Nutzeffekt solcher Exceptions auf Null reduziert. Denn eine Exception macht meistens nur dann Sinn wenn sie auch sichtbar wird und somit die Ausnahme auch ersichtlich ist.

Gruß hagen

[negaH]

Ah eines habe ich noch vergessen. Betrachten wir einfach mal eine Funktion X

Delphi-Quellcode:

function X(Input): Output;

Wir SEHEN hier eine Schnittstelle zu einer Black-Box. Wie SEHEN einen Namen X(), einen Eingabeparameter Input und einen Ausgabe Paramater Output. Das alles ist super und entspricht absolut dem Black Box Prinzip.
Nun führen wir aber in diese Funktion in deren Implementation eine Exception ein. Wird diese ausgelösst so zerstört sie das Black-Box-Prinzip denn WIR SEHEN diese Exception NICHT in der Schnittstelle !!??

Exception sind also einerseits ein produktives Mittel aber andererseits ein möglicherweise kontrapoduktives Design da sie aus Sicht der Schnittstelle nicht sichtbar sind.

Nun, die RTL, VCL etc.pp. enthalten 1000'ende von Funktionen, Methoden und Events und bei keinem sehen wir ob der Source darin auch Exception auslösen kann. Wie reagieren die Programmierer auf diesen Umstand ? Entweder sie analysieren jede Sourcezeile all dieser Funktionen (was im Grunde schwachsinnig gegen das Black-Box-Konzept verstösst oder aber der Programmiere beginnt wild umsich zu try except'en und zerstört somit im Grunde den Nutzen der Exceptions. Das sind die Folgen eines schlechten Designes, und die Ursache liegt darin begründet das wir in der Schnittstelle unserer Funktionen/Merthoden etc. pp. eben nicht SEHEN welche Exception zu erwarten sind.

Gruß Hagen