Exception Handling.

[Luckie]

Ich habe mir gerade mal etwas Gedanken über Exceptions gemacht und wie man einen Code wasserdicht bekommt. Dies ist mein Ergebnis:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  TEXT = 'Dies ist ein Testtext.';
  FILENAME = 'c:\test.txt';
var
  fs: TFileStream;
  s: String;
begin
  s := TEXT;
  try  {1}
    fs := TFileStream.Create(FILENAME, fmCreate);
    try  {2}
      try  {3}
        fs.WriteBuffer(Pointer(s)^, length(s));
      except
        on E: EWriteError do ShowMessage(E.Message);
      end;
    finally
      FreeAndNil(fs);
    end;
  except
    on E: Exception do ShowMessage(E.Message);
  end;
end;

Jetzt frage ich mich, das ist doch der blanke Wahnsinn: Drei verschachtelte try-Blöcke!

{1}: Um die Exception abzufangen, wenn die Methode Create von TFileStream fehlschlägt. Hier bringe ich zwar auch nur die Fehlermeldung, die die Exception selber bringen würde, aber eventuell will man ja noch was anders machen.
{2}: Der obligatorische Ressourcenschutzblock.
{3}: Um die Exception abzufangen, die WriteBuffer auslöst, wenn was schief geht beim Schreiben.

Ist das denn normal oder übertreibe ich hier? Wie gesagt, meine ShowMessages steh da nur für alternativen Code. Das heißt will man anstatt den ShowMessages noch was anderes machen, dann müssen drei try-Blöcke sein - oder?

[negaH]

Delphi-Quellcode:

  TEXT = 'Dies ist ein Testtext.'; 
  FILENAME = 'c:\test.txt'; 
var 
  fs: TFileStream; 
  s: String; 
begin 
  s := TEXT; 
  try  
    fs := TFileStream.Create(FILENAME, fmCreate); 
    try 
      fs.WriteBuffer(Pointer(s)^, length(s)); 
    finally 
      FreeAndNil(fs); 
    end; 
  except 
    on E: EWriteError do ShowMessage(E.Message) else 
      on E: Exception do ShowMessage(E.Message); 
  end; 
end;

Dürfte das gleiche machen. Im Grunde sollte man pro Procedure mit einem try finally und einem try except auskommen können.

Gruß Hagen

[Luckie]

Hm. Gut. Sollte klappen.

Machen wir mal etwas weiter. Folgender Code:

Delphi-Quellcode:

type
  EInvalidPW = class(Exception);

const
  PASSWORD = 'test';

procedure CheckPWD(Pwd: String);
resourcestring
  rsInvalidPw = 'Ungültiges Passwort';
begin
  if Pwd <> PASSWORD then
    raise EInvalidPW.Create(rsInvalidPw);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    CheckPWD('tset');
  except
    on E: EInvalidPW do ShowMessage(E.Message);
  end;
end;

Einfaches Beispiel, aber man sieht deutlich eine Funktion die True oder False zurück gibt hätte es auch getan. Wo liegt konkret der Vorteil von Exceptions? Oder anders gefragt, wann ist das werfen von Exceptions sinnvoll?

[dizzy]

Ganz genau das wollte ich mal meine Profs fragen. Der einzige Grund, den ich mir vorstellen kann, ist dass wenn eine Ausnahmesituation NICHT vom Programmierer behandelt wird, so stürzt der Rechner zumindest nicht ab, sondern es wird statt dessen eine unbehandelte Exception ausgelöst und angezeigt.

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 :roll:
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!? Das ist in meinen Augen völlig unnötige "Theorisierung" - zwanghaftes Anpassen an ein theroetisches Konzept. OOP ist SUPER! Keine Frage. Aber man muss es doch nicht auf Biegen und Brechen bis in alle Nieschen reinzwängen wollen...

Danke Luckie! Bin ich doch nicht ganz so alleine mit meinem Gefühl :)


gruss,
dizzy

[Luckie]

Nun ja, ich habe da eigentlich kein Gefühl, da ich weniger mit dem Bauch als mehr mit meinem Kopf - zu mindest versuche ich es - programmiere, deswegen frage ich hier. ;)

[c113plpbr]

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

Am beispiel von StrToInt:

Delphi-Quellcode:

function StrToInt_(const S: string; out E : boolean) : integer;
var
  x : integer;
begin
  Val(S, result, x);
  E := x <> 0;
end;

Wenn die (ausgegebene) Variable E true ist, dann gab es keinen Fehler, wenn nicht, gab es einen. 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.
Diese Methode ist zwar umständlich, aber manchmal hilfreich.

ciao, Philipp

[mirage228]

Zitat:

Zitat von c113plpbr

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

Am beispiel von StrToInt:

Delphi-Quellcode:

function StrToInt_(const S: string; out E : boolean) : integer;
var
  x : integer;
begin
  Val(S, result, x);
  E := x <> 0;
end;

Wenn die (ausgegebene) Variable E true ist, dann gab es keinen Fehler, wenn nicht, gab es einen. 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.
Diese Methode ist zwar umständlich, aber manchmal hilfreich.

ciao, Philipp

Hi,

oder du benutzt die eingebaute Funktion TryStrToInt von Delphi ;)

mfG
mirage228

[MathiasSimmack]

Ist die neu? Oder meinst du die, an die ich denke: "StrToIntDef".

[mirage228]

Zitat:

Zitat von MathiasSimmack

Ist die neu? Oder meinst du die, an die ich denke: "StrToIntDef".

Hi,

ja, anscheinend ist die neu in Delphi 6 (oder erst 7?).

Code:

function TryStrToInt(const S: string; out Value: Integer): Boolean;

Beschreibung

TryStrToInt konvertiert den String S, der ein Integer repräsentiert (in dezimaler oder hexadezimaler Form), in eine Zahl und weist diese Value zu. Wenn S keine gültige Zahl enthält, gibt TryStrToInt false zurück; ansonsten true.

Edit: Verflixte Tags :twisted:

mfG
mirage228

[Luckie]

Könnten wir bitte beim Thema bleiben? Danke.

@Hagen: Was mir gerade bei deinem Code einfällt: Wenn das Schreiben eine Exception auslöst, wird dann auch das Objekt wieder freigegeben? Um das nämlich sicher zustellen, habe ich es nämlich so geschachtelt.

[MathiasSimmack]

1. Wir sind immer noch beim Thema, denn

Zitat:

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:

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:

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:

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 :roll:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Zitat von negaH

Exceptions sollten nach Möglichkeit nur zur Fehlerbehandlung benutzt werden, AUCH wenn man reine Ausnahmebedinungen damit realisieren könnte.

:shock: ... ist das dein Ernst?

Zitat:

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:

Zitat von negaH

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

:shock: ... 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:

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:

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:

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:

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:

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:

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.

:gruebel: ... du hast zuviel Schopenhauer gelesen ;)

Zitat:

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 ... :zwinker:

Zitat:

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:

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:

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:

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

[Olli]

Zitat:

Zitat von negaH

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.

Ich habe die gleiche Beobachtung gemacht, aber andere Schlüsse gezogen. So denke ich bspw., daß es vielmehr so ist, daß viele Firmen nur kurzfristig orientieren. So ist das aktuelle Projekt wichtiger (und das rechnet man ja gegenüber einem Kunden ab) als die Zukunftsorientiertheit.

Beispiel: In der Firma, auf die ich anspiele, werden 2 Systeme eingesetzt um die Oberfläche für Kontrollstationen in Fabriken zu designen. Nun ist es so, daß ich mich krampfhaft an dem Design der einen (in der Firma beliebteren) Software orientieren mußte und deshalb in zahlreiche Schwierigkeiten kam. Stattdessen wäre es möglich gewesen eine Bibliothek aus für beide Systeme einheitlichen ActiveX-Controls zu erstellen, die dann für ein einheitliches Aussehen und "corporate identity" gesorgt hätten. Das ist ist aber unbeliebt, weil man es nicht direkt an den Kunden weitergeben kann (bzw. dann bei einer Ausschreibung schlechter dasteht).

Zitat:

Zitat von 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.

Da stimme ich dir zu, allerdings muß dann IMO der Programmierer sich weiterbilden. So einfach ist das. Beispiel: in den heutigen SMP- und HT-Systemen (oder sogar kombiniert, oder Dual-Core usw.) muß ich auch auf die Parallelisierung achten. Mache ich das nicht, habe ich den falschen Job. Und da meine ich noch nichtmal parallele Ausführbarkeit, sondern einfach nur drauf achten, daß prinzipiell der Code mal auf der einen und mal auf der anderen CPU laufen kann. Bei Treibern muß ich das auch beachten.

Zitat:

Zitat von negaH

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.

Volle Zustimmung! (Einschränkung: dies ist bei Delphi so, siehe ganz unten)

Zitat:

Zitat von negaH

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

150%ige Zustimmung!

Zitat:

Zitat von negaH

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

... siehe oben. Sehe ich skeptisch, wenn auch eine gemeinsame Grundlage unabdingbar ist. Wenn es aber der kleinste gemeinsame Nenner (i.e. der döfste Programmierer im Team) ist, dann ist es schlecht.

Zitat:

Zitat von negaH

4.) das Eintreffen/Auslösen solche asynchrone Exceptions/Events möglichst reduzieren.

Bei der RTL kann ich auch mitgehen.

Zitat:

Zitat von negaH

Nichts ist schlimmer wenn eine solche Funktion tief im Inneren eines Programmes ständig Exceptions auslösst.

Dann ist aber Punkt 2 wieder gefragt. Denn Exceptions heißen ja nicht umsonst Exceptions (also Ausnahmen).

Zitat:

Zitat von negaH

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 !!??

Dies wäre ja eine Vermischung von OOP und PP - ergo inkonsequent. Deswegen hast du recht, es ist nicht praktikabel.

Zitat:

Zitat von negaH

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

Bei Klassen sind sie dies aber (oder zumindest dokumentiert). Daher Exceptions bei OOP, ansonsten nur die Exceptions (aka SEH) vom OS (AV oder ähnliches). Beide sind verschiedene Konzepte.

Zitat:

Zitat von negaH

[...] oder aber der Programmiere beginnt wild umsich zu try except'en und zerstört somit im Grunde den Nutzen der Exceptions.

Aber es reicht doch an sich für den Programmierer die Erkenntnis, daß er eine Exception nicht am Ort des Auftretens behandeln muß - ergo muß er auch nicht "try except'en" und das Problem ist gelöst. Einfach die Exception durchschlagen lassen bis zum letzten eigenen Handler (notfalls zum OS). Wozu ist es zB gut eine Exception, welche ausgelöst wurde, weil eine unbedingt nötige Ressource nicht geholt werden konnte, an Ort und Stelle behandelt wird? Eben, garnichts! Einfach durchschlagen lassen.
Der letzte fängt die Exception :zwinker:

Zitat:

Zitat von negaH

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.

Dazu gibt es Code-Dokumentationen ;) ... und wenn wir uns mal angucken, daß Objekte eigentlich erstellt werden um wiederbenutzt zu werden, dann muß dem Benutzer auch eine Doku vorliegen.

Um es auf einen Punkt zu bringen
Für mich gehören try-except-Blöcke in die OOP-Welt und try-finally-Blöcke in die PP-Welt. Daß sie bei Delphi vermischt auftreten, haben wir der Tatsache zu verdanken, daß sie Objekte in Delphi nicht wie Stackvariablen verhalten (man sie also explizit freigeben muß, was oft in try-finally-Blöcken geschieht). Nichts dagegen, daß dies überhaupt möglich ist (auch in C++ kann ich über Objektzeiger gehen), aber in Delphi gibt es eben nur diese eine Möglichkeit. Ich gehe aber davon aus, daß Delphi.NET dafür eine Antwort hat. Robert_G? Anwesend? Sag mal was :mrgreen:

Korrektur: Natürlich geht es auch in Delphi (nämlich mit Interfaces), aber eben nur über Umwege. Und wenn jetzt irgendjemand kommt und das unsägliche object vorschlägt, dann bin ich aber raus aus der Diskussion. Das existiert bekanntlich nur für die Kompatibilität mit älteren Quelltexten.

EDIT2: jbg's Einwand eingearbeitet.

[jbg]

Zitat:

Zitat von Olli

Und wenn jetzt irgendjemand kommt und das unsägliche TObject vorschlägt, dann bin ich aber raus aus der Diskussion. Das existiert bekanntlich nur für die Kompatibilität mit älteren Quelltexten.

Du meinst wohl object. TObject ist bei Delphi eine class.

Natürlich bietet Delphi.NET da eine Möglichkeit: Das .Free einfach weglassen (sofern die Klasse kein Dispose() braucht).

Um auf das angeben von Exceptions im Interface zu kommen. Java hat dies in die Syntax eingebaut: "void bla() throws MyException". Das macht meines erachtens aber nur solange Sinn, wie man die Exceptions direkt vor Ort behandelt. Denn wenn man die nun durchzuschleifen probiert, hat man das Problem, dass man bei allen Methoden das throws anpassen muss, was bei größeren Projekten (mit einer kleinen Änderung im Kern: neue Exception) dann zu einer Sisyphusarbeit ausartet.

[negaH]

Hi Olli,

es ist schwer eine solche Grundsatzdiskussion über das Netz zu führen. Lieber würde ich sowas in einer persönlichen Diskussion klären. Denn im Grunde vertreten wir ähnliche Ansichten, der Unterschied zwischen uns besteht nur darin aus welchem Winkel wir die Problematik betrachten und was für Schlüsse wir letzendlich daraus ziehen.

Zitat:

Aber es reicht doch an sich für den Programmierer die Erkenntnis, daß er eine Exception nicht am Ort des Auftretens behandeln muß ....

Doch er muß es eben, ob er will oder nicht. Was heist "Exception behandeln" konkret ?. Dahinter steht ein Vorgang, einerseits ein Denkvorgang denn der Programmierer muß schon vor der Benutzung einer Schnittstelle wissen welche Ausnahmebedingungnen auftreten können, wie und ob er darauf in seinem Code reagieren muß. Der nächste Vorgang ist die Impelmentierung in der er eventuell eben doch spezielle Ausnahmen absichtlich abfangen muß. Eben weil Indy zb. die EConnectionCloseGracefully ausgelöst wurde, die nur signalisiert das die Connection beendet wurde.
In beiden Fällen bedeutet ein solcher "Vorgang" eben Zeit, somit Geld und Nerven. Das verkompliziert sich noch wenn man nun Funktionen benutzt die wiederum Funktionen benutzen die im Grunde alle eine Exception auslösen können.
Ergo: Der Programmierer müsste auf Grund der fehlenden Information wo und wann Exceptions ausgelösst werden entweder die "auf Nummer sicher gehen Methode" anwenden und alle Exceptions permanent abfangen, oder aber die "Ignorieren Methode" und verzichtet auf die aktive Einflußnahme des Programmablaufes beim Eintreffen einer Exception.

BEIDES ist aber kontraproduktiv, denn ein programmiertes Feature macht nur dann effektiv Sinn wenn es mir Arbeit abnimmt und einsparrt, und nicht zus. Zeit kostet weil es im Grunde in der Schnittstelle undokumentiert ist.

Und schwups sind wir bei der Dokumentation. Ein sauberer Source sollte komplett ohne Doku auskommen können, denn warum sollte Goethe ein Buch schreiben um eine Dokumentation zum Lesen eines seiner anderen Bücher zu haben. Das ist doch idtiotisch, und im übertragenen Sinne ist es noch idiotischer auf einen Source bezogen. Denn in dieser Form der Sprache haben WIR die Regeln festgelegt und diese Regeln arbeiten immer nach dem Prinzip einer öffentlichen Schnittstellendeklaration und einer Black Box Implementation.
Leider verstoßen aber immer mehr OOP Ansätze exakt gegen dieses Konzept. Exceptions sind nicht in der Methoden/Funktions Deklaration kenntlich gemacht, sie werden innerhalb der Black Box ausgelösst. Aus diesem Grunde geht der Vorteil der Schnittstelle und dem Black Box Prinzip kaputt denn der Entwickler muß nun doch wissen ob innerhalb der Black Box eine Exception auftreten kann. Ergo: der Source muß dies separat dokumentieren, er wird also auf Grund seiner Schnittstellen Deklaration nicht mehr selbsterklärbar sein, und schwups wieder ein alter Vorteil verloren.

Ich möchte hier nicht gegen Exceptions argumentieren, sondern eher das dahinterliegende Konzept im Gesamtkonzept der Programmiermethoden analysieren. Und deshalb meinte ich eingangs das Exception tatsächlich in jedlicher Weise eine Ausnahme darstellen. Der Grad ihrer Nützlichkeit ist also sehr schmal für uns Programmierer.

Gruß Hagen

[Flocke]

Jetzt gebe ich auch noch mal meinen Senf dazu (obwohl ich den immer noch nicht mag...)

1. Bedeutung des Begriffs Exception

Für mich widerspricht es dem eigentlichen Sinn wenn man Exceptions dazu benutzt, einfache Fehlerbedingungen zu signalisieren. Für mich ist eine Exception im wörtlichen Sinne eine Ausnahmebedingung: eine Programmzustand, in dem nicht mehr mit der normalen Ausführung fortgefahren werden kann. Nicht genug Speicher, unzureichende Systemresourcen, die CD mit der EXE-Datei des Programms wurde aus dem Laufwerk genommen oder ähnliches, und sicher auch Programmierfehler wie fehlerhafte Indizes. Ganz bestimmt aber nicht so etwas wie ein einfacher Fehlerzustand. Der kann zwar stellenweise asynchron auftreten, also ohne direkten Bezug zur aktuell aufgerufenen Prozedur, aber ich denke das ist kein Grund aus einem Ereignis (-> Event) eine Exception (-> Ausnahmebedingung) zu machen.

2. Was der "normale" Programmierer daraus macht

In meinen Augen macht ein Block wie

Delphi-Quellcode:

try
  TueIrgendWas;
except
  on E: Exception do
    MessageDlg(E.Message, mtError, [mbOk], 0);
end;

überhaupt keinen Sinn - da kann ich die Exception auch gleich bis zum obersten Level durchschlagen lassen, dort wird nämlich auch einfach eine Meldung ausgegeben. Diese Form sieht man aber am häufigsten. Noch schlimmer ist, dass die meisten Programmierer dann den Fehler machen, einfach im Code fortzufahren als ob nichts geschehen wäre, der try-except Block in diesem Fall also gerade eine Dummheit ist.

3. Was ich daraus mache

Persönlich benutze ich Exception-Handling fast ausschließlich für try-finally Blöcke zum Ressourcenschutz. Nur an bestimmten Stellen verwende ich try-except und zwar dort, wo ich mit einem möglichen Fehlschlagen rechne. Z.B. wenn ich ein TFileStream ohne vorherige Abfrage mit FileExists öffne, was ja sowieso wenig Sinn macht, denn es kann ja sein dass es die Datei gibt aber ich sie trotzdem nicht öffnen darf.

4. Der Nutzen

Praktisch finde ich durchaus, dass SEH den Sourcecode übersichtlicher macht. Ich finde z.B. die erste Variante wesentlich besser zu lesen als die zweite:

Delphi-Quellcode:

procedure Variante1;
begin
  TueDies;
  TueDas;
  if StimmtDas then
    TueIrgendWas
  else
    TueWasAnderes;
  // Kein Rückgabewert notwendig, Exception
  // schlägt durch in die aufrufende Routine
end;

function Variante2: boolean;
begin
  if TueDies <> 0 then
    Result = false  //<-- 1 signalisiert Fehler
  else if TueDas in [0, 7, 24] then
    Result = false  //<-- 0 = nicht gefunden, 7 = zu groß, 24 = zu alt
  else
  case StimmtDas of
    5, 13: Result = false;  //<-- Fehlercodes
    1: Result := TueIrgendWas = 1;
    0: Result := TueWasAnderes = 0;
  end;
end;

Ich kann mich noch gut an die ersten Code-Beispiele von Microsoft zur Windows-API / GDI-Programmierung erinnern, wo hinter jedem Prozeduraufruf (GetDC, CreateBrush, SelectObject, DeleteObject, ReleaseDC) immer wieder der ganze Salmon hing, also jedesmal eine separate Fehlerbehandlung mit abschließendem return. Ich denke da ist SEH die bessere Alternative.

<Vorbehalt="Muss ich noch mal genau drüber nachdenken">
5. Exceptions zur Fehlerbehandlung

Um eine Exception für die normale Fehlerbehandlung zu "missbrauchen" fehlt ein ganz wichtiges Feature, nämlich das Fortfahren an der Fehlerstelle. Im Grunde so etwas wie das "Resume Next" in Visual Basic. Dann könnte man nämlich in Fällen wie beim "EConnectionClosedGracefully" den Fehler dankend zu Kenntnis nehmen und an der alten Stelle fortfahren.
</Vorbehalt>

Hinweis: Nachträglich noch etwas editiert, um es strukturierter aussehen zu lassen :angel2:

[Olli]

Zitat:

Zitat von jbg

Du meinst wohl object. TObject ist bei Delphi eine class.

Ja, tue ich. Danke für den Hinweis.

Zitat:

Zitat von jbg

Um auf das angeben von Exceptions im Interface zu kommen. Java hat dies in die Syntax eingebaut: "void bla() throws MyException".

C++ ebenfalls. Man sieht die Wurzeln von Java ;)

Zitat:

Zitat von jbg

as macht meines erachtens aber nur solange Sinn, wie man die Exceptions direkt vor Ort behandelt. Denn wenn man die nun durchzuschleifen probiert, hat man das Problem, dass man bei allen Methoden das throws anpassen muss

Bei neueren C++-Compilern dient das Attribut nur als "Dokumentationshilfe".

Zitat:

Zitat von jbg

was bei größeren Projekten (mit einer kleinen Änderung im Kern: neue Exception) dann zu einer Sisyphusarbeit ausartet.

Ja, hast ja recht. Ich meine auch nicht, daß man jede Exception durchschlagen lassen muß.

Nochmal mein Beispiel. Ich habe eine Molekülklasse geschrieben, die intern sog. Tripods ("Dreibeine") benutzt um 2 Atome und 3 Bindungen darzustellen. Nach außen ist das nicht sichtbar. Im Sinne der Effizienz ist es nun so, daß man von außen auf beliebige Bindungen oder Atome zugreifen kann (auch nichtexistente!). Intern ist es wie gesagt ein 2D-Array dieser Tripods. Ist der Zugriff nicht erfolgreich ("out of range") behandele ich die Exception lokal und erweitere das Array und ggf. erstelle ich das vorher nicht vorhandene Tripod-Objekt. Hier werden Exceptions sehr sinnvoll eingesetzt und sind nach außen nicht sichtbar.

Zitat:

Zitat von negaH

es ist schwer eine solche Grundsatzdiskussion über das Netz zu führen. Lieber würde ich sowas in einer persönlichen Diskussion klären. Denn im Grunde vertreten wir ähnliche Ansichten, der Unterschied zwischen uns besteht nur darin aus welchem Winkel wir die Problematik betrachten und was für Schlüsse wir letzendlich daraus ziehen.

Kann sein. Wir kriegen das aber auch noch auf die Reihe (persönliche Diskussion) :-D

Zitat:

Zitat von negaH

BEIDES ist aber kontraproduktiv, denn ein programmiertes Feature macht nur dann effektiv Sinn wenn es mir Arbeit abnimmt und einsparrt, und nicht zus. Zeit kostet weil es im Grunde in der Schnittstelle undokumentiert ist.

Stimmt!

Zitat:

Zitat von negaH

Und schwups sind wir bei der Dokumentation. Ein sauberer Source sollte komplett ohne Doku auskommen können

Du meinst ohne externe Dokumentation? Für mich gehen "externe" Dokumentation und Kommentare Hand in Hand, weil ich u.a. doxygen verwende.

Zitat:

Zitat von negaH

Denn in dieser Form der Sprache haben WIR die Regeln festgelegt und diese Regeln arbeiten immer nach dem Prinzip einer öffentlichen Schnittstellendeklaration und einer Black Box Implementation.

Aber genau deswegen muß doch eine Dokumentation existieren (sei es nun in Form von Kommentaren im Text oder extern). :gruebel:
Allein die Wahl eines Methodennamens muß ja nicht sonderlich clever sein. Wenn die Dokumentation existiert ist's aber kein Problem.

Zitat:

Zitat von negaH

Aus diesem Grunde geht der Vorteil der Schnittstelle und dem Black Box Prinzip kaputt denn der Entwickler muß nun doch wissen ob innerhalb der Black Box eine Exception auftreten kann. Ergo: der Source muß dies separat dokumentieren, er wird also auf Grund seiner Schnittstellen Deklaration nicht mehr selbsterklärbar sein, und schwups wieder ein alter Vorteil verloren.

Ich verstehe was du meinst. Wo ist aber der Nachteil? Ob ich nun Fehlercodes dokumentiere oder Exceptions (die sogar noch komplexeres tun können) ist doch einerlei.

Zitat:

Zitat von negaH

Ich möchte hier nicht gegen Exceptions argumentieren, sondern eher das dahinterliegende Konzept im Gesamtkonzept der Programmiermethoden analysieren. Und deshalb meinte ich eingangs das Exception tatsächlich in jedlicher Weise eine Ausnahme darstellen. Der Grad ihrer Nützlichkeit ist also sehr schmal für uns Programmierer.

Das ist wohl wahr.

[Olli]

Keine rote Box. Sorry, will dich natürlich nicht ignorieren ;)

Ich stimme in den Punkten 1-4 vollständig mit dir überein.

Zitat:

Zitat von Flocke

Ich kann mich noch gut an die ersten Code-Beispiele von Microsoft zur Windows-API / GDI-Programmierung erinnern, wo hinter jedem Prozeduraufruf (GetDC, CreateBrush, SelectObject, DeleteObject, ReleaseDC) immer wieder der ganze Salmon hing, also jedesmal eine separate Fehlerbehandlung mit abschließendem return. Ich denke da ist SEH die bessere Alternative.

Zumal in Delphi ja kein - ich nenne es mal - "premature return" möglich ist, weil man immer "result:=xyz; Exit;" machen muß.

Zitat:

Zitat von Flocke

Um eine Exception für die normale Fehlerbehandlung zu "missbrauchen" fehlt ein ganz wichtiges Feature, nämlich das Fortfahren an der Fehlerstelle. Im Grunde so etwas wie das "Resume Next" in Visual Basic. Dann könnte man nämlich in Fällen wie beim "EConnectionClosedGracefully" den Fehler dankend zu Kenntnis nehmen und an der alten Stelle fortfahren.

Kannst du eigentlich. In diesem Fall mußt du ja gerade lokale Behandlung durchführen.

Aber wenn wir schon bei Windows' SEH sind. Das bietet das. Nur die meisten Compiler machen nicht komplett Gebrauch von allen Features (bzw. reichen nicht alle zum Benutzer/Programmierer durch).
Genaugenommen kannst du an einer beliebigen Stelle deines Codes mit beliebiger Registerbelegung fortfahren. Wenn die Exception aber vorher durchschlug, wurde der Stack schon aufgeräumt, will heißen ein Fortfahren ist nicht ohne weiteres möglich. Der Stack müßte gesichert und wiederhergerstellt werden um das zu ermöglichen.

[negaH]

Hi Olli

Zitat:

Zitat:

Denn in dieser Form der Sprache haben WIR die Regeln festgelegt und diese Regeln arbeiten immer nach dem Prinzip einer öffentlichen Schnittstellendeklaration und einer Black Box Implementation.

Aber genau deswegen muß doch eine Dokumentation existieren (sei es nun in Form von Kommentaren im Text oder extern).
Allein die Wahl eines Methodennamens muß ja nicht sonderlich clever sein. Wenn die Dokumentation existiert ist's aber kein Problem.

Sie sollte aber das Ziel der Programmierung sein. D.h. ein un-cleverer Methodenname ist eine Schlamperei in der Programmierung und benötigt zusätzliche Arbeit in einer Dokumentation.

Zitat:

Zitat:

Aus diesem Grunde geht der Vorteil der Schnittstelle und dem Black Box Prinzip kaputt denn der Entwickler muß nun doch wissen ob innerhalb der Black Box eine Exception auftreten kann. Ergo: der Source muß dies separat dokumentieren, er wird also auf Grund seiner Schnittstellen Deklaration nicht mehr selbsterklärbar sein, und schwups wieder ein alter Vorteil verloren.

Ich verstehe was du meinst. Wo ist aber der Nachteil? Ob ich nun Fehlercodes dokumentiere oder Exceptions (die sogar noch komplexeres tun können) ist doch einerlei.

Konstantennamen SIND Bestandteil der Programmiersprache, zusaätzliche Dokumentationen zu dieser Konstante sind NICHT Bestandteil des Programmes.


Nein. Es sollte garkeine Dokumentation geben, das wäre am besten !!
Die Programmier-Sprache sollte auf jegliches Element das eine Information zu einer Information liefert verzichten. Denn es kann niemals eine Information zu einer Information geben, das ist unlogisch. Die eigentliche Information verkommt zu einer redundanten und schon bekannten Nachricht. Eine zusätzliche Dokumentation eines Sources wäre vergleichbar mit einer Information zu einer Nachricht. Eine Nachricht enthält aber keine für uns neue und nützliche Information. Somit wird der eigentlich geschrieben Source zu einer belanglosen Nachricht und IN der Dokumentation steckt eigentlich exakt das drinnen an Information die in den Source gehören würde. Der Programmierer hat geschlampt.
Die IDEALE Programmier-Sprache ist eine Sprache die ein Problem für die Machine und den Menschen absolut ohne zus. Informationen in Form von Dokumentationen erklärbar und verständlich macht.
Schau mal, auch wir brauchen in unserer natürlichen Sprache keine zusätzliche Sprache um das was wir ausdrücken wollen nochmals in dieser zus. Sprache, genannt Dokumentation, deutlich auszudrücken. Wir benötigen nur eine Sprache und mehr nicht. Wir sollten und werden eines Tages in einer Programmiersprache programmieren die exakt diesen Forderungen entspricht und sehr sehr ähnlich zu unserer natürlichen Sprache funktioniert. Aber am wesentlichsten an dieser Sprache wird es sein das es keine Nachrichten gibt, sprich sie wird in jeder Quelltextzeile absolute Information enthalten, ohne Redundanz und ohne Nachrichten.
Man kann sich nun streiten ob eine Dokumentation zu einem Source + dem Source ein komplettes Program darstellt, sprich zwei untrennbare Bestandteile des Programmes sind. Ich behaupte mal nicht, denn nur der eigentliche Source stellt den Ablaufplan des Programmes dar. Die ideale Sprache würde also reinen Source enthalten und denoch wäre dieser Source gleichmaßen ideal verständlich für uns Menschen und gleichermaßen ideal übertragbar auf eine Machine.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Nein. Es sollte garkeine Dokumentation geben, das wäre am besten !!

Hier haben wir einen eindeutigen Dissenz. IMO ist es die Pflicht eines jeden Programmierers seinen Code zu kommentieren, es sei denn es ist das Werk von weniger als 2h! Tut er das nicht, muß er sich in seinen eigenen Code u.U. wieder "hineinlesen".

Zitat:

Zitat von negaH

Die Programmier-Sprache sollte auf jegliches Element das eine Information zu einer Information liefert verzichten. Denn es kann niemals eine Information zu einer Information geben, das ist unlogisch.

Dann ist es unlogisch, daß du soviele redundante Worte benutzt! Redundanz ist essentiell für einen Menschen. Sonst könntest du ja keinen Kontext aufbauen.

Zitat:

Zitat von negaH

Die eigentliche Information verkommt zu einer redundanten und schon bekannten Nachricht.

Möglicherweise, aber nicht en detail - oder schlimmer noch, stell dir die Win32-API ohne Dokumentation vor!

Zitat:

Zitat von negaH

Man kann sich nun streiten ob eine Dokumentation zu einem Source + dem Source ein komplettes Program darstellt, sprich zwei untrennbare Bestandteile des Programmes sind. Ich behaupte mal nicht, denn nur der eigentliche Source stellt den Ablaufplan des Programmes dar. Die ideale Sprache würde also reinen Source enthalten und denoch wäre dieser Source gleichmaßen ideal verständlich für uns Menschen und gleichermaßen ideal übertragbar auf eine Machine.

Menschen sind aber nunmal nicht ideal :zwinker:

[DGL-luke]

Ich finde Exceptions sind eine gute waffe gegen Funktionen mit booleschem Rückgabewert ;)

Wenn in der JVCL bei den Indies aber "Verbindung erfolgreich geschlossen" eine Ausnahme darstellt, würde ich mir überlegen, warum ich diese komponenten benutze( :mrgreen: ) - am Ende sind wir bei Java, wo ja gelegentlich "Fatal Error: No Error" gemeldet werden soll...

Eigentlich wollte ich ja auf die redundanz zu sprechen kommen: Redundanz ist gut, wenn es um komplexe zusammenhänge geht, bei denen hintergrundinfo hilft. redundanz ist schlecht, wenn es um bandbreite geht :mrgreen:

Natürlich wäre ein Programmierstil, der keine Dokumentation mehr verlangt, ideal.

Aber würde das nicht in deskriptiven Sprachen(ergo Overhead=Redundanz), oder zumindest in Funktuionsdeklarationen wie

Delphi-Quellcode:

function A_und_B_werden_und_addiert_ausgegeben(A,b:integer):integer

enden? ohne redundanz geht es nicht - ob jetzt mit oder ohne Kommentaren, Dokumentation oder anschaulichen Funktionsnamen.

Denn ist nicht schon add(a,b:integer):integer ein enormer overhead? viel effektiver wäre doch f 372(x,y:2):2, oder?

aber wie bereits gesagt: je komplexer das thema/die methode, desto mehr redundanz braucht der mensch.
Auch wenn der Code noch so schön eingerückt ist, solange man nicht Neo heisst, wird man kaum aus dem reinen Lesen des Quellcodes das Programm vor sich Ablaufen sehen. Zumindest bei genügender Komplexität des Problems.

ich fasse zusammen: Soviel Redundanz wie nötig, so wenig Dokumentation wie möglich. Aber bitte nicht auf koreanisch ;)

EDIT: sachlichen fehler korrigiert. Sorry an die JVCL ;)

[Olli]

Zitat:

Zitat von DGL-luke

ich fasse zusammen: Soviel Redundanz wie nötig, so wenig Dokumentation wie möglich.

Aus welcher Sicht argumentierst du? Benutzer (auch Programmierer) oder Autor einer Klasse?

[DGL-luke]

Aus der Sicht des gesunden Menschenverstandes. :zwinker: (Ich behaupte ja nicht, dass ich einen hätte :mrgreen: )

Zu viel Redundanz bedeutet: Man braucht länger, bis man es verstanden hat, da man ja das unnütze Beiwerk mitlesen muss.
Zu wenig aber bedeutet, dass man evtl. nicht genügend information bekommt, nämlich die, die der autor vorausgesetzt und deswegen weggelassen hat.

Für den Benutzer sollte natürlich z.B. eine GUI so selbsterklärend sein, dass er keine Dokumentation braucht.
Aber auch hier gilt wieder: Mit zusätzlicher Komplexität - z.B. Funktionen, die nur selten benutzt werden - braucht man eine Dokumentation.

Code ist aber selten selbsterklärend - deshalb sollte sich der Programmierer schon die Mühe machen, hier und da oder zumindest bei mathematischen Operationen Kommentare einfließen zu lassen.

Auch eine Klasse KANN selbsterklärend sein - sobald das ganze allerdings über ein paar Funktionen wie savetofile, draw und create hinausgeht, muss man eine Dokumentation zur Verfügung stellen.

[jbg]

Zitat:

Zitat von DGL-luke

Wennin der JVCL aber "Verbindung erfolgreich geschlossen" eine Ausnahme darstellt, würde ich mir überlegen, warum ich diese komponenten benutze( :mrgreen: )

Ganz einfach: Die JVCL macht sowas nicht. Das sind die Indy-Komponenten. Also bitte nicht ein OS-Projekt kritisieren, das dafür gar nichts kann.

Zitat:

Auch eine Klasse KANN selbsterklärend sein - sobald das ganze allerdings über ein paar Funktionen wie savetofile, draw und create hinausgeht, muss man eine Dokumentation zur Verfügung stellen.

Nicht unbedingt. Man hat ja die Möglichkeit die Methoden in Gruppen zusammenzufassen, was ja wieder eine zusätzliche Information darstellt. So kann der Leser aus dem Zusammenhang der Methoden erkennen, was diese ungefähr machen. Aber um dieses "ungefähr" ganz zu erfassen, braucht es dann schon eine Doku, oder die Implementierung.

[Olli]

Zitat:

Zitat von DGL-luke

Zu viel Redundanz bedeutet: Man braucht länger, bis man es verstanden hat, da man ja das unnütze Beiwerk mitlesen muss.

Redundanz bedeutet erstmal Kontext. Wenn eine Dokumentation unnützes Beiwerk enthält, ist es ein Roman, keine Dokumentation. Das wäre sonst ein Oxymoron. Es mag sein, daß nicht alle Teile einer Dokumentation für dich relevant sind, aber es geht ja nicht um dich allein.

Hier mal eine Information: Apfel, Pferd

Was will ich dir damit wohl sagen? All die schmückenden Worte sind redundant, aber nur mit denen kannst du überhaupt verstehen, was ich dir sagen will.

Zitat:

Zitat von DGL-luke

Für den Benutzer sollte natürlich z.B. eine GUI so selbsterklärend sein, dass er keine Dokumentation braucht.

Wenn ich oben von Benutzer sprach, so war dies zB der Benutzer einer Klasse (also ein Programmierer wie auch du).

Zitat:

Zitat von DGL-luke

Aber auch hier gilt wieder: Mit zusätzlicher Komplexität - z.B. Funktionen, die nur selten benutzt werden - braucht man eine Dokumentation.

Angenommen du hast nur einen Header zu einer Funktion/Klasse - und diese Funktion oder Klasse ist tatsächlich nur eine Blackbox für dich, dann geht's eben tatsächlich nicht ohne Doku. Aber im Sinne der Wartbarkeit geht es IMO schon ab einer gewissen Größe des Projektes nicht mehr ohne Dokumentation. Wundert mich eigentlich, daß Hagen das nicht schon in die gemeinsame Arbeitsbasis ("Codestil") eingefaßt hatte.

Zitat:

Zitat von DGL-luke

Auch eine Klasse KANN selbsterklärend sein - sobald das ganze allerdings über ein paar Funktionen wie savetofile, draw und create hinausgeht, muss man eine Dokumentation zur Verfügung stellen.

Eine Klasse kann intuitiv sein, aber IMO nicht wirklich selbsterklärend. Denn wenn die Klasse über einen Container für "public" "properties" hinausgeht, dann tun irgendwelche Methoden irgendwas. Das braucht eine Doku.

Zitat:

Zitat von jbg

Aber um dieses "ungefähr" ganz zu erfassen, braucht es dann schon eine Doku, oder die Implementierung.

:thumb: vollste Zustimmung! Das meinte ich mit intuitiv. Klar ist es intuitiv, wenn ich einer C++-Klasse einen überladenen operator+/operator+= mitgebe. Aber wie sind die Details der Speicherverwaltung etc. pp., auf was muß ich ggf. achten ...

[DGL-luke]

stimme euch zu, und habe den fehler korrigiert.

Zum unnützen Beiwerk:

Man muss sich einfach überlegen, welchen Wissensstand der durchschnittliche Leser der Dokumentation hat - desto geringer dieser, desto mehr Kontext braucht man. In einem Mathebuch für Gymnasiasten steht mehr drin als in einer Formelsammlung für Ingenieure. Und genau das meine ich damit.

[Olli]

Zitat:

Zitat von DGL-luke

In einem Mathebuch für Gymnasiasten steht mehr drin als in einer Formelsammlung für Ingenieure. Und genau das meine ich damit.

Alles klar. In diesem Fall hast du natürlich recht. Leider kann man ja schlecht für alle Niveaus eine extra Doku schreiben. Daher gibt es Foren wie die DP :zwinker: