AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Best Practice: Wann verwendet ihr Exceptions in Funktionen?

Best Practice: Wann verwendet ihr Exceptions in Funktionen?

Ein Thema von Zacherl · begonnen am 10. Dez 2013 · letzter Beitrag vom 11. Dez 2013
Antwort Antwort
Seite 1 von 4  1 23     Letzte » 
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#1

Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 16:38
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
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Benutzerbild von Aphton
Aphton

Registriert seit: 31. Mai 2009
1.198 Beiträge
 
Turbo Delphi für Win32
 
#2

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 16:49
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.
das Erkennen beginnt, wenn der Erkennende vom zu Erkennenden Abstand nimmt
MfG
  Mit Zitat antworten Zitat
hathor
(Gast)

n/a Beiträge
 
#3

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:05
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;
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#4

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:17
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.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org

Geändert von Phoenix (10. Dez 2013 um 17:25 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.013 Beiträge
 
Delphi 12 Athens
 
#5

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:29
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. Delphi-Referenz durchsuchenIntToStr muß eine Exception werfen, aber Delphi-Referenz durchsuchenTryIntToStr gibt nur den Boolean zurück und Delphi-Referenz durchsuchenVal einen "Fehlercode", bzw. die Fehlerposition.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (10. Dez 2013 um 17:32 Uhr)
  Mit Zitat antworten Zitat
nahpets
(Gast)

n/a Beiträge
 
#6

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:31
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.
  Mit Zitat antworten Zitat
OlafSt

Registriert seit: 2. Mär 2007
Ort: Hamburg
284 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#7

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:34
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.
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#8

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:38
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)
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#9

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:39
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

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.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.062 Beiträge
 
#10

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 17:40
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.

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.

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.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:08 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz