Best Practice: Wann verwendet ihr Exceptions in Funktionen?

[Zacherl]

Hallo zusammen,

gibt es ein Bestimmtes Schema, an das ihr euch haltet, wenn es um die Verwendung von Exceptions in Funktionen geht? Ich bin mir nie sicher, wann es sinnvoller ist eine Exception zu schmeißen, statt einen boolschen Rückgabewert zu verwenden.

Beispiel:
Eine Funktion, die viele subsequente API Aufrufe macht. Bei Exceptions könnte ich den Namen der API und den Error Code zurückgeben. Wenn ich mit einem boolschen Rückgabewert arbeite, kann ich nur signalisieren dass EINER der API Aufrufe fehlgeschlagen ist und den Error Code außerhalb mit GetLastError erfragen.

Zu wissen welche API fehlgeschlagen ist, kann sehr nützlich sein, wenn auf dem eigenen System alles funktioniert, aber ein Kunde / Anwender nicht nachvollziehbare Probleme hat.

Viele Grüße
Zacherl

[Aphton]

Daran wäre ich auch interessiert.

Mir scheints so, als ob Exceptions eigentlich genau für diesen Zweck geschaffen worden sind (Sprachkonstrukt) - daher sollte man, wenn man sauber programmieren will, diese verwenden!

Ich habe aber keine berufspraktische Erfahrungen und kann nicht wirklich sagen, was sich bewährt.

[hathor]

Wenn ich z.B. ein XML-File auslese in verschiedenen WINDOWS-Versionen,
muss ich damit rechnen, dass nicht alle Werte vorhanden sind.

Delphi-Quellcode:

...
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/SystemScore');
    Form1.Memo1.lines.add(Format(' 1. SystemScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/MemoryScore');
    Form1.Memo1.lines.add(Format(' 2. MemoryScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/CpuScore');
    Form1.Memo1.lines.add(Format(' 3. CpuScore          %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/VideoEncodeScore');
    Form1.Memo1.lines.add(Format(' 4. VideoEncodeScore  %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/GraphicsScore');
    Form1.Memo1.lines.add(Format(' 5. GraphicsScore     %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/GamingScore');
    Form1.Memo1.lines.add(Format(' 6. GamingScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/DiskScore');
    Form1.Memo1.lines.add(Format(' 7. DiskScore         %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;

[Phoenix]

Exceptions sind genau das, was sie Aussagen: Ausnahmen.

Man sollte eine Exception nur genau dann werfen, wenn das Modul das gerade Arbeitet wirklich in eine Situation kommt, die es nicht mehr korrekt Abarbeiten kann. Im Falle einer tatsächlich möglichen und erwarteten Fehlersituation sollte keine Exception geworfen werden.

Was man unbedingt vermeiden sollte ist, Exceptions zum Kontrollfluss zu verwenden. Das führt sehr schnell zu Spaghetticode und damit zu schlecht wartbaren Systemen.

Hathor hat da natürlich auch gerade eine Paradebeispiel für dieses Anti-Pattern geliefert. Wenn ich schon davon ausgehen muss, das bestimmte Knoten nicht vorhanden sind, dann kann ich deren Existenz vorher abprüfen und entsprechend sauber mit if/else Statements darauf reagieren. Das ist keine Ausnahme, sondern ein möglicher und je nach WIndows-Version vollkommen normaler Zustand.

Wenn allerdings der Root-Knoten in meinem XML der falsche ist, dann wäre das eine Ausnahme (z.B. falsches File gelagen?) mit der ich in meinem Code nicht umgehen kann. Hier kann ich dann Problemlos eine Exception werfen.

Edit Nachtrag:
Noch was zum Thema warum Exceptions nur selten genutzt werden sollten.
1.) Sind Exceptions im Code äquivalent zu nicht-lokalen und optionalen GOTO's. Sie brechen den Programmfluss an einer Stelle hart ab, und der nächste Einsprungspunkt liegt (oder auch nicht) in komplett anderem (nämlich ggf. irgend einem X Ebenen höher aufrufenden) Codeblock. Das macht die ganze Sache zu Spaghetti- und unwartbaren Code.
2.) Gehen die Designer des Compilers und der Runtime auch davon aus, das Exceptions seltene Ausnahmefälle darstellen. Dementsprechend ist der Code für das Exception-Handling üblicherweise (da nur selten verwendet) nicht hochoptimiert. Das Werfen einer Exception ist in Sachen Performance in aller Regel eine sehr teure Operation.

[himitsu]

Wenn nahezu immer mit einem Fehler zu rechnen ist und/oder wenn der Fehler "egal" ist, dann ein Boolean.
Auch wenn man den Fehler "schnell" z.B. via IF mit einer alternativen Variante behenben kann.

Zusätzlich kann man SetLastError oder eine Variable nutzen, um "erweiterte" Informationen weiterzugeben. (globale Variable, Property usw.)

-

Wenn unterschiedliche Fehler auftreten können und man daruaf reagieren können soll, dann z.B. HRESULT, Integer oder ein Enum, für erweiterte Informationen.

-

Wenn es ein "schwerwiegender" Fehler ist, bei dem die hauptsächliche Funktion nicht gewährleistet ist
und/oder wenn "selten" Fehler auftreten
oder wenn die "ausführliche" Fehlerinformation nicht ordentlich als Result zurückgegeben werden können *1,
dann Exceptions.

*) z.B. wenn es schon ein Result gibt und man in Diesem auf keine "ungültigen" Werte als Fehlerinformationen nutzen kann (z.B. siehe ShellExecute)

-

z.B. IntToStr muß eine Exception werfen, aber TryIntToStr gibt nur den Boolean zurück und Val einen "Fehlercode", bzw. die Fehlerposition.

[nahpets]

Hallo,

meine persönlich Ansicht zu dem Thema (man kann sie teilen, muss es aber nicht):

Exceptions benutze ich grundsätzlich nicht als Rückgabewert. Nie!!!

Eine Exception weist mich immer auf einen Fehler hin, bei dem ich "zu blöd" war, ihn durch eine vernünftige Programmierung abzufangen.
Eine Exception ist immer eine Ausnahmesituation, in der versucht wird zu retten, was noch zu retten ist.
Sie dient niemals zur Steuerung irgendwelcher Programmabläufe.

Kann mich an ein Programm erinnern, dass ich von einem anderen Entwickler übernehmen musste. Er steuerte den Programmablauf durch Exceptions. Bei ihm gab es sowas wie EGoodException und EBadException (die hießen wirklich so und waren von EException abgeleitet). Und dann gab es noch etliche "Zwischendinger", die für mehr oder weniger gute oder schlechte Situationen genutzt wurden. Für mich persönlich läuft das unter "sehr schlechtem Programmierstil".

In dem besagten Programm war es extrem schwierig herauszubekommen, in welchem Programmteil es nach den diversen Exceptions nun weiterging bzw. was zur Fehlerbehandlung diente.

Es erinnert mich an andere Programme, die ich mal mitpflegen durfte (Basic bzw. PL/1). Dort wurde der Programmablauf nie in der Form

Delphi-Quellcode:

if x = y then begin
...
end;

gesteuert, sondern immer in der Form

Delphi-Quellcode:

if not (x = y) then GoTo Pxyz;
...
Hier dann die Logik für die Bedingung x = y
...
Goto Pxyz;

wobei xyz eine nummerischer Wert von 000 bis 999 sein konnte.

Extrem schwer, sich dort einzulesen und zurechtzufinden.
Funktionen oder Prozeduren wurden dort nicht genutzt, in Basic eventuell mal ein GoSub, aus dem aber durchaus per GoTo irgendwo in den Quelltext zurückgesprungen wurde, aus dem das GoSub aufgerufen wurde oder per GoTo irgendwo in so ein Sub mitten "hineinaberneineberneinabernein" und dann irgendwie mit GoTo wieder raus, da der "normal" Rückweg hinaus ja dann nicht funktioniert.

Mit dieser Methode und "Steuerung per Exception" kann man wunderbaren Spagetticode erstellen, dessen Unpflegbarkeit quasi mit der Erstellung schon sichergestellt ist.
Für meine Begriffe ist dieses Vorgehen hochgradig unprofessionell. Habe bisher keine Software kennengelernt, die dauerhaft mit derartigen Konstrukten wartbar und weitereinwickelbar war.

Exception bedeutet meines Wissens Ausnahme und nicht Regel.

Exceptions dienen zur Ausnahmebehandlung (in der Regel ist dies die Fehlerbehandlung) und nicht zur regulären Programmsteuerung.

http://de.wikipedia.org/wiki/Ausnahmebehandlung

Was hathor beschreibt ist keine "Funktionssteuerung" per Exception statt Rückgabewert, sondern eine Fehlerbehandlung. Im Fehlerfalle wird eine alternative Ausgabe gemacht. Die Funktion selbst behandelt die Fehler (hier fehlende Inhalte). Bei einer Fehlerbehandlung "per Exception" müsste hier für jeden der möglichen Fehler eine spezielle Exception existieren und natürlich auch für jede der daraus möglichen Kombinationen, da diese Funktion ja offensichtlich bei allen Fehlern schon selbst etwas macht bzw. die Fehler bei einer Exceptionsteuerung sammeln müsste, um sie dann gemeinsam weiterzugeben. Jeder einzelne Fehler kann ja nicht mit einer eigenen Exception zurückgegeben werden, ohne den Programmablauf nach dem ersten Fehler zu unterbrechen. In dem Falle wäre eine Exceptionsteuerung mit einem nicht unerheblichen Programmieraufwand und einem nicht unerheblichen "Unübersichtlichkeitsfaktor" verbunden. Viel Vergnügen beim Implementieren.

Funktionen können bei korrekter Verarbeitung z. B. True und im Fehlerfalle False zurückgeben. Der Rest kann durchaus per VAR-Parameter zurückgegeben werden. Als Rückgabewert und/oder VAR-Parameter sind aber durchaus auch Records oder Klassen mit entsprechenden Attributen möglich. Hier geht (bei durchdachter Planung) deutlich mehr als ein "geht" oder "gehtnicht" (True / False).

Phoenix hat mit seiner Aussage absolut recht.

[OlafSt]

Ab und zu ist es mal interessant, den generierten Assemblercode seines Programms zu betrachten. Wenn man dann sieht, was der Compiler an Massen von Code produziert, um so einen try..except-Block "abzuwickeln", wird einem echt übel und es wundert einen nicht mehr, das das Programm so elend vor sich hin schneckt.

Da beginnt man dann rasch wieder damit, Exceptions für seinen eigentlichen Zweck zu benutzen: Das Abfangen unvorhergesehener Probleme, damit das programm dann stabil bleibt. Zur Flusssteuerung sind Exceptions mehr als nur ungeeignet.

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1239311)

Hathor hat da natürlich auch gerade eine Paradebeispiel für dieses Anti-Pattern geliefert.

Schnippeldi-Refaktor-DRY:

Delphi-Quellcode:

Procedure ReadNode (string title, nodeKey);
Begin
  try
      Nodes := XmlDoc.selectNodes(nodeKey);
      Form1.Memo1.lines.add(Format('%20s %s',[title,Nodes.Item(0).Text]));
  except  
    on E:Exception do 
      Form1.Memo1.lines.add(string,Format('---> %s not exists.',[title]); 
  end;
End;
...
  ReadNode('1. SystemScore'     ,'//WinSAT/WinSPR/SystemScore');
  ReadNode('2. MemoryScore'     ,'//WinSAT/WinSPR/MemoryScore');
  ReadNode('3. CpuScore'        ,'//WinSAT/WinSPR/CpuScore');
  ReadNode('4. VideoEncodeScore','//WinSAT/WinSPR/VideoEncodeScore');
  ReadNode('5. GraphicsScore'   ,'//WinSAT/WinSPR/CpuScore'); 
  ReadNode('6. GamingScore'     ,'//WinSAT/WinSPR/GamingScore'); 
 ...

Ich kann mir nicht helfen: Eher ein Paradebeispiel, wie lesbar Code mit Exceptions wird (Und das ist noch nicht einmal gut refaktorisiert)

[Zacherl]

Zum Kontrollfluss missbrauche ich meine Exceptions auf jeden Fall nicht. Ich denke eher, dass ich in manchen Situationen zu wenig Exceptions verwende. Nehmen wir mal als konkretes Beispiel mal eine simple DLL Injection, welche aus einer Abfolge der APIs

1. OpenProcess
2. VirtualAllocEx
3. WriteProcessMemory
4. CreateRemoteThread

besteht. Hier ist es so, dass die komplette Funktion fehlschlägt, wenn auch nur eine einzige dieser API Aufrufe nicht erfolgreich ist. Demnach würde hier jeweils die Situation eintreten, dass meine Funktion nicht mehr korrekt Arbeiten kann.

Ich habe nun zwei Möglichkeiten:

1. Nach jedem API Aufruf die Rückgabe prüfen und bei Fehlschlag eine Exception in der Funktion schmeißen
2. Bei einem fehlerhaften API Aufruf die komplette Funktion abbrechen, FALSE zurückgeben, außerhalb der Funktion die Rückgabe prüfen und dann eine Exception schmeißen

:arrow: Die Exception schmeißen müsste ich also so oder so, nur ist die Frage, ob dies an zentraler Stelle (außerhalb der Funktion) oder dezentral (evtl. mit genaueren Informationen) innerhalb der Funktion geschieht.

@himitsu:
Ein HRESULT als Rückgabe wäre natürlich eine Alternative zum Boolean, aber hier habe ich die Befürchtung, dass der Code recht schnell unübersichtlich werden könnte. Zumindest müsste ich mir bezogen auf mein obiges Beispiel dann verschiedene Konstanten für ERROR_API1_FAILED, ERROR_API2_FAILED, ... anlegen.

@nahpets:
Ein Record als Rückgabeparameter erscheint mir jetzt spontan als "ungewöhnlicher Stil", aber ist vermutlich gar keine schlechte Idee. Hier könnte ich neben einem Indikator für FAIL oder SUCCESS zusätzlich noch den Namen der fehlgeschlagenen API zurückgeben.

[JasonDX]

Ich werfe immer dann Exceptions, wenn ein Fall auftritt der ein Verhalten erfordert, das nicht von der Methode selbst kontrolliert werden soll. Andernfalls handhabt die Methode den Fehler entsprechend. Hilfreich ist in solchen Fällen auch, filterbare Log-Ausgaben zu generieren.
Durch Fehlercodes über Rückgabewerte zu kommunizieren finde ich befremdlich. Man kann nur wenig Informationen über den Fehler mitgeben, und es passiert allzuleicht, Fehler zu ignorieren (Viel Spaß beim Debuggen). Deswegen sollte diese Variante weitmöglichst vermieden werden.

Zitat:

Zitat von Phoenix (Beitrag 1239311)

Noch was zum Thema warum Exceptions nur selten genutzt werden sollten.
1.) Sind Exceptions im Code äquivalent zu nicht-lokalen und optionalen GOTO's. Sie brechen den Programmfluss an einer Stelle hart ab, und der nächste Einsprungspunkt liegt (oder auch nicht) in komplett anderem (nämlich ggf. irgend einem X Ebenen höher aufrufenden) Codeblock. Das macht die ganze Sache zu Spaghetti- und unwartbaren Code.

Es hängt stark von "selten nutzen" ab - aber im Endeffekt sind Exceptions keineswegs GoTos, und haben einen sehr linearen Verlauf. Wenn ein Fehler auftritt, den man in der Methode selbst nicht behandeln kann hat man mehrere Möglichkeiten:
1. man ignoriert den Fehler (ouch)
2. man meldet dem Aufrufer über Rückgabewert oder Parameter, dass ein Fehler aufgetreten ist
3. man schmeißt eine Exception
Excepions sind da die Wahl der Qual. Zudem bieten sie weitaus saubereren Code und können viel Informationen über den Fehler mitgeben, um die bestmögliche Fehlerbehandlung zu erlauben.

Zitat:

Zitat von Phoenix (Beitrag 1239311)

2.) Gehen die Designer des Compilers und der Runtime auch davon aus, das Exceptions seltene Ausnahmefälle darstellen. Dementsprechend ist der Code für das Exception-Handling üblicherweise (da nur selten verwendet) nicht hochoptimiert. Das Werfen einer Exception ist in Sachen Performance in aller Regel eine sehr teure Operation.

Richtig. Normalerweise wird auch in Performance-intensiven Anwendungen erst die Eingaben auf Fehler geprüft, dann der aufwendige Task gestartet.

[jaenicke]

Zitat:

Zitat von Zacherl (Beitrag 1239319)

:arrow: Die Exception schmeißen müsste ich also so oder so, nur ist die Frage, ob dies an zentraler Stelle (außerhalb der Funktion) oder dezentral (evtl. mit genaueren Informationen) innerhalb der Funktion geschieht.

Und genau an der Stelle sind Exceptions genau richtig. Es handelt sich um eine Ausnahme vom regulären Programmablauf und du kannst an der Stelle nicht weitermachen und auch der Aufrufer kann an der Stelle nicht ohne Fehlerbehandlung weitermachen. Damit das korrekt behandelt werden kann, lieferst du mit der Exception die nötigen Informationen. Genau dafür sind Exceptions da.

Das hat an der Stelle auch nichts mit Programmsteuerung zu tun. Dafür sind sie, zumindest in den allermeisten Fällen in der Tat ungeeignet.

[himitsu]

Was man auch nicht vergessen darf:
Exception im Programmablauf machen das Debuggen nicht grade leichter,
also bezüglich "damit den Programmfluß zu steuern".

Delphi-Quellcode:

try
  i := StrToInt(S);
except
  i := 0;
end;

Jetzt debuggt mal einen Code, wo sowas alle 2 Sekunden durchlaufen wird und öfters keine Zahl im S drin steckt.

[Sir Rufo]

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:

Delphi-Quellcode:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 <> INVALID_HANDLE then
  begin
    LHandle2 := GetHandleFromElsewhere( LHandle1 );
    if LHandle2 <> INVALID_HANDLE then
    begin
      LHandle3 := GetHandleFromElsewhere( LHandle2 );
      if LHandle3 <> INVALID_HANDLE then
      begin
        LHandle4 := GetHandleFromElsewhere( LHandle3 );
        if LHandle4 <> INVALID_HANDLE then
        begin
          DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
        end;
      end;
    end;
  end;
end;

Jetzt mal mit Exceptions

Delphi-Quellcode:

type 
  EInvalidHandleException = class( Exception );

procedure CheckInvalidHandle( AHandle : THandle; const AText : string );
begin
  if AHandle = INVALID_HANDLE then
    raise EInvalidHandleException.Create( AText );
end;

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElseWhere;
  CheckInvalidHandle( LHandle1, 'from ElseWhere' );

  LHandle2 := GetHandleFromElseWhere( LHandle1 );
  CheckInvalidHandle( LHandle2, 'from ElseWhere' );

  LHandle3 := GetHandleFromElseWhere( LHandle2 );
  CheckInvalidHandle( LHandle3, 'from ElseWhere' );

  LHandle4 := GetHandleFromElseWhere( LHandle3 );
  CheckInvalidHandle( LHandle4, 'from ElseWhere' );

  DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
end;

[himitsu]

Zitat:

Zitat von Sir Rufo (Beitrag 1239328)

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Ja, das schon, aber nur solange recht "selten" mal ein Handle nicht geliefert werden konnte.

Wobei du aber auch die Funktionsweise von foo geändert hast.
Beim ersten foo, mit den IFs, bekommt keiner mit, ob DoSomethingWithHandles verarbeitet wurde.

[Der schöne Günther]

Zitat:

Zitat von Furtbichler (Beitrag 1239318)

Schnippeldi-Refaktor-DRY:

Abgesehen davon, dass ich die Methode eher PrintNode genannt hätte: Entsprechend dokumentiert ist die Methode doch super: Die Methode ist kurz, knackig, übersichtlich und verhält sich für den Benutzer absolut vorhersehbar.


Wobei ich im "Vier Handles"-Beispiel jetzt grübele, warum man nicht einfach die Funktion um einen "Erfolgreich?"-Rückgabe-Boolean erweitert und statt einer Exception einfach mit

Delphi-Quellcode:

Exit(False)

rausspringt. Finde ich ok und tue es oft ohne mich zu schämen.

[Zacherl]

Zitat:

Zitat von Der schöne Günther (Beitrag 1239336)

Wobei ich im "Vier Handles"-Beispiel jetzt grübele, warum man nicht einfach die Funktion um einen "Erfolgreich?"-Rückgabe-Boolean erweitert und statt einer Exception einfach mit

Delphi-Quellcode:

Exit(False)

rausspringt. Finde ich ok und tue es oft ohne mich zu schämen.

Genau das mache ich bisweilen auch sehr häufig. Dann hat man allerdings wieder mein anfängliches Problem, dass man nicht genau weiß, welcher der API Aufrufe fehlgeschlagen ist. Ist zwar bei lokalem Debugging nicht so wild, weil man einfach mal schnell durch die Funktion steppen kann, aber wenn das Problem nur bei einem Kunden / Anwender auftritt, hat man ein Problem.

[hathor]

Zitat:

Zitat von Furtbichler (Beitrag 1239318)

Zitat:

Zitat von Phoenix (Beitrag 1239311)

Hathor hat da natürlich auch gerade eine Paradebeispiel für dieses Anti-Pattern geliefert.

Schnippeldi-Refaktor-DRY:

Delphi-Quellcode:

Procedure ReadNode (string title, nodeKey);
Begin
  try
      Nodes := XmlDoc.selectNodes(nodeKey);
      Form1.Memo1.lines.add(Format('%20s %s',[title,Nodes.Item(0).Text]));
  except  
    on E:Exception do 
      Form1.Memo1.lines.add(string,Format('---> %s not exists.',[title]); 
  end;
End;
...
  ReadNode('1. SystemScore'     ,'//WinSAT/WinSPR/SystemScore');
  ReadNode('2. MemoryScore'     ,'//WinSAT/WinSPR/MemoryScore');
  ReadNode('3. CpuScore'        ,'//WinSAT/WinSPR/CpuScore');
  ReadNode('4. VideoEncodeScore','//WinSAT/WinSPR/VideoEncodeScore');
  ReadNode('5. GraphicsScore'   ,'//WinSAT/WinSPR/CpuScore'); 
  ReadNode('6. GamingScore'     ,'//WinSAT/WinSPR/GamingScore'); 
 ...

Ich kann mir nicht helfen: Eher ein Paradebeispiel, wie lesbar Code mit Exceptions wird (Und das ist noch nicht einmal gut refaktorisiert)

Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.
Es ständig neu zu erzeugen und zu verwerfen macht auch keinen Sinn.

Dieser sinnlose VERBESSERUNGSTRIEB mancher "Zeitvertreiber" ist auch der Grund, warum ich hier meine Projekte nicht veröffentliche!

[Der schöne Günther]

Der Beitrag doch sogar eigentlich vollkommen zu deinen Gunsten? Hier muss doch niemand etwas beweisen und außerdem haben wir uns alle gern :party:

[Meflin]

Zitat:

Zitat von Sir Rufo (Beitrag 1239328)

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:

Delphi-Quellcode:

...

Jetzt mal mit Exceptions

Delphi-Quellcode:

...

Na sorry aber das ist ja jetzt Äpfel mit Birnen verglichen. Das Beispiel ohne Exceptions kann man genauso leserlich und ohne verschachtelte ifs aufschreiben und trotzdem keine Exceptions verwenden... indem man einfach Guard Clauses benutzt. Soll heißen:

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

[JasonDX]

Zitat:

Zitat von Meflin (Beitrag 1239347)

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

In diesem Beispiel sind Exceptions tatsächlich nicht notwendig, denn der Fall der geprüft wird, wird nicht direkt als Fehlerfall gehandhabt wird. Aber: Nehmen wir an, die Methode hat als Voraussetzung, dass alle 4 Handles gegeben sind. Wie sieht dann die If-Abfrage aus, bzw. wie wird dem Aufrufer am besten mitgeteilt, dass die Daten, die übergeben wurden, nicht valide waren?

Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.

[Furtbichler]

Zitat:

Zitat von hathor (Beitrag 1239340)

Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.

Na ja, die Prozedur könnte eine lokale Prozedur sein, oder XmlDoc ist ein Feld einer Klasse oder eine globale Variable oder es war einfach nur Pseudocode und sollte nur den Sinn von Refactoring und DRY demonstrieren. In jedem Fall hast Du natürlich recht, sie kann nicht funktionieren: Ich habe sie nämlich noch gar nicht gespeichert :stupid:

Zitat:

Dieser sinnlose VERBESSERUNGSTRIEB

Wenn das für dich sinnlos ist, dann weiß ich auch nicht. Aber jeder soll so programmieren, wie er es für richtig hält. Das Lustige an DRY ist übrigens, das Du die Prozedur 'ReadNode' ohne Probleme anpassen kannst (z.B. den Fehler loggen), und zwar an dieser einen Stelle. Alle Aufrufe werden sich automatisch und logischerweise dann genau gleich verhalten. Bei deiner Copy&Paste-Vorgehensweise müsstest Du dann an allen Stellen das gleiche machen und wehe Du vertippst dich oder vergisst eine Stelle.

Denk mal drüber nach. Und wenn Du schon dabei bist (am Nachdenken), überlege Dir auch noch, ob dich überhaupt jemand kritisiert hat und wieso Du hier so ausrastest. Ich wollte Dir jedenfalls nicht an den Karren pissen.

Zitat:

Zitat von Der schöne Günther (Beitrag 1239336)

...dass ich die Methode eher PrintNode

oder 'ProcessNode' oder so.

Das Handle-Beispiel könnte man auch so lösen, das die 'GetHandleFromElsewhere'-Methode die Exception-Behandlung übernimmt. Oder man macht soetwas:

LHandle1 := CheckHandle (GetHandleFromElseWhere, 'From ElseWhere');
LHandle2 := CheckHandle (GetHandleFromElseWhere (LHandle1), 'From ElseWhere 1');
LHandle3 := CheckHandle (GetHandleFromElseWhere (LHandle2), 'From ElseWhere 2');
LHandle4 := CheckHandle (GetHandleFromElseWhere (LHandle3), 'From ElseWhere 3');

...
Wobei das CheckHandle eine Funktion ist:

Delphi-Quellcode:

Function CheckHandle (aHandle : THandle; Msg : String) : THandle;
Begin
  if aHandle = InvalidHandle then Raise Exception.Create(Msg);
  result := aHandle;
End;

Macht Delphi z.T. ja auch so.

Ich persönlich finde das aber nicht sooo lesbar. Es ist zu empfehlen, wenn man die GetXXXX-Funktionen nicht ändern kann.

Man kann die aber Kapseln, sodaß die Exception-Behandlung im Wrapper stattfindet. Solch ein Code (3-Zeiler) kann ruhig komisch aussehen, da schaut man kurz rein, sagt:'Ach so' und macht das Zeugs wieder zu. Die Wrapper sind dann aber sehr gut zu lesen:

Delphi-Quellcode:

Try
  LHandle1 := GetHandle;
  LHandle2 := GetHandle(LHandle1);
  LHandle3 := GetHandle(LHandle2);
  LHandle4 := GetHandle(LHandle3);
  DoSomething(LHandle1,LHandle2,LHandle3,LHandle4);
Except
  On E:EInvalidHandle Do begin 
    LogError(E);
    Raise EMoreAbstractException.Create(E); 
  End;
End;

Und das ist dann schon wieder schön knackig.
Die 'EMoreAbstractException' analysiert die innere Exception (kann ja unterschiedliche Gründe haben) und erzeugt eine Exception, die die Details verschweigt. Der Aufrufer interessiert sich ja nicht dafür, das der USB-Treiber aufgrund ungültiger Installationsparameter im 3.Duktus links kein Handle bereitstellen kann. Wichtig ist: 'Es funzt net'. Details stehen im Log.

@JasonDX: Wenn da wirklich nur ein Return erfolgen soll, ist das grenzwertig. Meist ist so ein stillschweigendes Scheitern schlechter Stil. WENN es aber genaus so sein soll, ist das mit dem Return schon so richtig.

Da ginge aber auch (besser?) sowas:

Delphi-Quellcode:

if not TryGetHandle (LHandle1) then return;
if not TryGetHandle (LHandle1,LHandle2) then return;
if not TryGetHandle (LHandle2,LHandle3) then return;
if not TryGetHandle (LHandle3,LHandle4) then return;

Wieder knackig kompakt :stupid:

[Meflin]

Zitat:

Zitat von JasonDX (Beitrag 1239348)

Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.

Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal ;) (on a related note: Ich finde auch das procedure-Konzept nicht wirklich sinnvoll :stupid:)

Exceptions sind mir persönlich einfach zu low level :mrgreen: Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

[JasonDX]

Zitat:

Zitat von Meflin (Beitrag 1239353)

Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal ;)

Mal abgesehen davon, dass der Code IMO schnell sehr unleserlich wird, was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null? (Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Zitat:

Zitat von Meflin (Beitrag 1239353)

Exceptions sind mir persönlich einfach zu low level :mrgreen: Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).

Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.
Ich denke kein Stück an Interrupts wenn ich eine Exception schmeiße, sondern daran, das gerade ein besonderer Fall in meinem Code aufgetreten ist, den ich in meiner derzeitigen Methode nicht behandeln kann.

Zitat:

Zitat von Meflin (Beitrag 1239353)

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions :gruebel: nehmen wir an ich habe eine Methode

Code:

parseUrl(String): Url

Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.

Code:

myUrl = parseUrl(input);

aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.

[Namenloser]

Zitat:

Zitat von Phoenix (Beitrag 1239311)

Exceptions sind genau das, was sie Aussagen: Ausnahmen.

Genau das wollte ich auch schreiben. Deiner weiteren Erläuterung stimme ich ebenfalls voll zu.

[Sir Rufo]

Zitat:

Zitat von JasonDX (Beitrag 1239366)

Zitat:

Zitat von Meflin (Beitrag 1239353)

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions :gruebel: nehmen wir an ich habe eine Methode

Code:

parseUrl(String): Url

Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.

Code:

myUrl = parseUrl(input);

aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.

Ein Null-Objekt setzt man auch nicht ein, um eine Exception-Behandlung zu ersetzen, sondern, da wo es passt, um den Code einfacher zu halten.

Denn ständig zu prüfen, ob es das Objekt gibt oder nicht um, wenn ja, es dann zu benutzen ist dann etwas umständlich.

Vor allem, wenn dann dieses Objekt auch noch von aussen angesprochen werden soll.

Delphi-Quellcode:

ILogger = interface
  procedure Log( const Text : string );
end;

TFoo = class
private
  FLogger : ILogger;
  function GetLogger : ILogger;
  procedure SetLogger( const Value : ILogger );
public
  property Logger : ILogger read Getlogger write SetLogger;

  procedure Bar;
end;

implementation

type
  TNullLogger = class( TInterfacedObject, ILogger )
    procedure Log( const Text : string );
  end;

procedure TNullLogger.Log( const Text : string );
begin
  // do nothing
end;

procedure TFoo.SetLogger( const Value : ILogger );
begin
  FLogger := Value;
end;

function TFoo.GetLogger : Ilogger;
begin
  if not Assigned( Flogger ) then
    FLogger := TNullLogger.Create;
  Result := Flogger;
end;

procedure TFoo.Bar;
begin
  Logger.Log( 'Bar from TFoo Start' );
  Logger.Log( 'Bar from TFoo Step 1' );
  Logger.Log( 'Bar from TFoo Step 2' );
  Logger.Log( 'Bar from TFoo Step 3' );
  Logger.Log( 'Bar from TFoo Stop' );  
end;

end.

Als Logger kann ich jetzt also irgendwas dort unterjubeln, allerdings kann ich zum Ausschalten des Loggens einfach ein

Delphi-Quellcode:

nil

übergeben, und trotzdem knallt es nicht, es wird aber auch nichts geloggt.

[Meflin]

Zitat:

Zitat von JasonDX (Beitrag 1239366)

was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null?

Das hast du falsch verstanden. Das ist so garnicht möglich. Du hast als Rückgabe z.B. ein Try[Int]. Dann ist das entweder ein Failure oder ein Success Objekt. Die konkrete Weiterverwendung ist dann sehr stark abhängig vom spezifischen Anwendungsfall. Aber du kannst mit dem Objekt erstmal weiterarbeiten, ohne zu wissen, was von beiden es ist. Also z.B.

Code:

maybeInt.map(x => x * 2)

Die Überprüfung, ob die ganze Geschichte erfolgreich war, musst du genau ein mal machen, nämlich zum Schluss, genau dann, wenn du das Endergebnis brauchst. Da man mehrere Trys auf diese Weise problemlos verketten kann, sparst du dir da SEHR VIEL Fehlerbehandlungscode.

Zitat:

(Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Ist richtig, aber dieser Fall hat nicht sonderlich viel mit funktionaler Programmierung zu tun (außer der Verwendung von Lambdas, die immer nützlich sind).

Zitat:

Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.

Ist mir schon klar, dass das nichts mit Interrupts zu tun hat. Was ich meinte war das Konzept "ich breche einfach mal mitten drin komplett ab, egal was ich gerade mache, und springe zu einer völlig anderen Codestelle", was beide durchaus gemeinsam haben.

Zitat:

Zitat von Meflin (Beitrag 1239353)

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions

Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):

Code:

interface IComputation {
  function currentValue: Float;
  function multiplyBy(other: Float): IComputation;
  function divideBy(other: Float): IComputation;
}

class Computation extends IComputation {
  
  function divideBy(other: Float): IComputation {
    if (other = 0) return new NullComputation();
    return new Computation(this.currentValue / other);
  }
  ...

}

class NullComputation extends IComputation {
  function currentValue: Float { return Float.NaN }
  function divideBy(other: Float): IComputation { return this; }
  ...
}

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN

[jaenicke]

Zitat:

Zitat von Meflin (Beitrag 1239377)

Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):

Code:

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN

In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1239381)

In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.

Indem in der Division-Methode ein Logging eingebaut wird. Viel hilft es zwar nicht, denn man kann ja nur loggen: 'Bei der Division von 1.2345/0' ist ein Fehler aufgetreten.

Bei Delphi ist es ja auch nicht soo einfach, den Grund einer Fehlrechnung zu erkennen:

Delphi-Quellcode:

Try
  A:=B/C/D/E/F;
Except
  On EDivideByZero do
    // Soll ich hier C,D,E,F prüfen? Blödsinn
    // Also, was tun?
...

Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:

Delphi-Quellcode:

Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap;

Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.

Wenn ich aber eine leere Bitmap nehme, kann ich transparent mit allen weiteren Methoden arbeiten, ohne auf Nil prüfen zu müssen, was den Code doch etwas unleserlich machen würde. Ich kann eine leere Bitmap skalieren (kommt eh ne leere Bmp raus), filtern, weichzeichnen, Kantenerkennung betreiben, speichern, laden, usw. usw.

Wenn ich einen Rand um eine leere Bmp zeichne, dann entsteht allerdings (je nachdem, ob ich das will) eine nichtleere Bmp oder wieder eine leere Bmp.

Noch ein Wort zu Exceptions. Wir verwenden Exceptions auch zur Validierung:

Delphi-Quellcode:

Procedure TStorage.Store (theObject : TSomeStuff);
Begin
  try
    theObject.Validate();
    Persist(theObject);
  Except
    On E:Exception Do HandleError(E);
  End
End;

Procedure TStorage.HandleError(E:Exception);
Begin
  If E is EValidationException then Raise; 

  If E is EPersitingException then begin
    Log('Probleme beim Speichern', E);
    Raise ECannotStoreException.Create('Speicherprobleme');
  end;
  
  if E is Exception then begin
    Log('Programmierfehler', E);
    Raise ECannotStoreException.Create('Programmierfehler');
  end;
end;

Alle Public-Methoden der TStorage-Klasse haben einen Try-Except-Wrapper, der HandleError aufruft. Alle Exceptions, mit Ausnahme der EValidationException, werden gekapselt.

Der Aufrufer muss dann nur die beiden Exceptions abfangen.

Bei einer Validation Exception weiß er dann, das er ne Meldung anzeigen kann und den Anwender die Chance gibt, seine Daten zu ändern.

Ansonsten kann nur eine ECannotStoreException auftreten. Die kann er auch auswerten und z.B. den Vorgang beenden, denn diese Exception bedeutet, das es (derzeit) nicht funktioniert. Konkret müsste man natürlich die genaue Fehlerursache ermitteln (indem der Persister z.B. geeignete Informationen bereitstellt).

Auf jeden Fall sieht der Validator immer gleich aus:

Delphi-Quellcode:

Procedure TSomeStuff.Validate;
Begin
  If SomeData<23 then Raise EValidationException.Create('SomeData too small');
...

Man kann hier auch mit Rückgabewerten arbeiten, aber wenn der Validator wieder andere Validatoren aufruft, wird das wieder nervig. Mit Exceptions bleibt der Code immer einfach zu lesen.

[Meflin]

Zitat:

Zitat von jaenicke (Beitrag 1239381)

In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.

Es hindert dich ja auch niemand daran, das Nullobjekt um beliebige Fehlerinformationen zu erweitern. Dann könntest du in diesem Fall, wenn du das denn wölltest, sogar konkret speichern, dass der Fehler genau bei der x-ten Berechnung aufgetreten ist. Und dann hast du schonmal deutlich mehr Infos, als mit dem äquivalenten Exception-Code (wie von Furtbichler gezeigt).

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1239382)

Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:

Delphi-Quellcode:

Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap;

Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.

Korrekt. Ich als .NET'ler überprüfe auch üblicherweise erstmal meine Argumente. In dem Fall würde ich auch gleich eine ArgumentNullException werfen. Wenn die Funktion nur in einem bestimmten Bereich skalieren kann, und width ausserhalb der validen Werte liegt, gibts auch gleiche ne ArgumentOutOfRangeException (oder eine mehr generische ArgumentException mit entsprechendem Fehlertext).

Sowas (= konkret eine Fehlbedienung) sollte maximal beim Entwickeln passieren und nicht im normalen Programmablauf. Und wenn doch, ist woanders was schief gelaufen (Ausnahmesituation) ;-) Da sind Exceptions natürlich das Mittel der Wahl.

[Der schöne Günther]

Und jetzt könnte man wieder wild darüber debatieren, ob der Aufrufer von

Delphi-Quellcode:

ScaleBmp

gezwungen sein sollte, die offensichtlich zu erwartenden EArgumentNull und EArgumentOutOfRange-Exception zu behandeln oder selbst kenntlich zu machen, dass er diese werfen könnte. 8-)

Macht das den Code lesbarer?

[Sir Rufo]

Zitat:

Zitat von Meflin (Beitrag 1239385)

Zitat:

Zitat von jaenicke (Beitrag 1239381)

In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.

Es hindert dich ja auch niemand daran, das Nullobjekt um beliebige Fehlerinformationen zu erweitern. Dann könntest du in diesem Fall, wenn du das denn wölltest, sogar konkret speichern, dass der Fehler genau bei der x-ten Berechnung aufgetreten ist. Und dann hast du schonmal deutlich mehr Infos, als mit dem äquivalenten Exception-Code (wie von Furtbichler gezeigt).

Allerdings hätte ich das Object als

Delphi-Quellcode:

NaNComputation

deklariert, weil es für diesen konkreten Fall benutzt wird.

Ob man Exceptions oder NullObjekt verwendet, hängt eben davon ab, ob es eine Ausnahme (falscher Zugriff) oder gewöhnlicher Anwendungsfall ist.

Exception weil ich die Grenzen beachten muss

Delphi-Quellcode:

type
  TMyList = class
    property Count;
    property Items[Index : Integer] : TItem read GetItem;
  end;

function TMyList.GetItems(Index : Integer) : TItem;
begin
  if Index >= Count then
    raise Exception;
  Result := ...
end;

NullObjekt

Im Hauptmenü gibt es den Menü-Punkt Drucken aber das Drucken wird nicht an jeder Stelle unterstützt (weil da gibt es nichts zum Drucken oder ist noch nicht implementiert oder das Druckmodul wurde nicht gekauft).
Die Aktion aus dem Hauptmenü holt sich trotzdem mit

Delphi-Quellcode:

CommandHandler.Command['print']

den Eintrag und bekommt eben mal ein echtes Objekt oder eben das NullObjekt.

Exceptions wären hier kontraproduktiv und eine Überprüfung von aussen macht die Verdrahtung aufwendiger. Hier kann jeder beliebige Befehl im Menü verdrahtet werden und die Implementierung kann erfolgen wann will.

Delphi-Quellcode:

ICommand = interface
  function CanExecute : Boolean;
  procedure Execute;
end;

TCommandHandler = class
  property Command[const Name : string] : ICommand read GetCommand;
end;

function TCommandHandler.GetCommand( const Name : string ) : ICommand;
begin
  if not FCommands.Contains( Name ) then
    Result := NullComand.Create
  else
    Result := FCommands[Name];
end;

NullCommand = class( TInterfacedObject, ICommand )
  function CanExecute : Boolean;
  procedure Execute;
end;

function NullCommand.CanExecute : Boolean
begin
  Result := False;
end;  

procedure NullCommand.Execute;
begin
end;

[jaenicke]

Zitat:

Zitat von Phoenix (Beitrag 1239388)

Korrekt. Ich als .NET'ler überprüfe auch üblicherweise erstmal meine Argumente. In dem Fall würde ich auch gleich eine ArgumentNullException werfen.

Wobei man das auch anders argumentieren kann:
Eine Bitmapreferenz, die nil ist, kann skaliert auch wieder eine nil-Referenz ergeben ohne dass ein Fehler vorliegt. Wenn dieser Wert vorher erlaubt ist, warum sollte eine Skalierungsfunktion dann dieses Verhalten ändern? Denn ist es nicht erlaubt, hätte es bereits vorher geprüft werden müssen.

Insofern gibt es immer mehrere Möglichkeiten, die von den Vorgaben abhängen. Es sollte nur innerhalb einer Klassenbibliothek konsistent sein.

[Furtbichler]

Zitat:

Zitat von Der schöne Günther (Beitrag 1239390)

Und jetzt könnte man wieder wild darüber debatieren, ob der Aufrufer von

Delphi-Quellcode:

ScaleBmp

gezwungen sein sollte, die offensichtlich zu erwartenden EArgumentNull und EArgumentOutOfRange-Exception zu behandeln oder selbst kenntlich zu machen, dass er diese werfen könnte. 8-)

Ich habe eine ähnliche Debatte mit den Fail-Fast-Verfechtern gehabt. Man gewöhnt sich an den contract:

Delphi-Quellcode:

Procedure TMyStuff.ScaleBitmap(aBitmap : TBitmap...);
Begin
  CheckNull(aBitMap,'TMyStuff.ScaleBitmap: aBitmap');
  ...

Zitat:

Zitat von jaenicke (Beitrag 1239397)

Eine Bitmapreferenz, die nil ist, kann skaliert auch wieder eine nil-Referenz ergeben

Das ist schwierig, wenn Du auf Methoden der Bitmap zugreifen willst. Wobei Delphi da ja doch ziemlich robust ist ('if self=nil then return'). So gesehen, doch nicht so schwierig :stupid: