Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten

[Dezipaitor]

Zitat von himitsu:

Wenn der Fehler vorhersehbar ist, dann ist es ja im weiteren Sinne keine "Ausnahme" mehr und es würde sich ein Fehlercode besser machen, als wenn man da gleich mit einer rießigen Exception nach dem User wirft.

Fehler sind immer vorhersehbar, solange es sich um Softwarefehler handelt, weil Computer deterministisch sind (nur ist der Aufwand wirklich groß). Damit kann man mit genügend Anstrengung und Aufwand alle möglichen Fehler vorhersehen.
Aber soviel Aufwand ist garnicht nötig, solange man nur seine eigenen Fehlerpfade definiert und dokumentiert. Siehe JWSCL.

Zitat:

Ich finde da die WinAPI super, da man dort 'ne ganze Reihe an Funktionen ausführen und deren "Ergebnis" nur mit Hilfe von If-Then "geziehlt" auswerten kann, ohne gleich jede Funktion einzeln in Try-Except zu stopfen ... ein einziges Try-Finally um Alles reicht da aus, um "echte" Ausnahmefälle zu behandeln.

Die C WinAPI besitzt keine Exceptions, weil das Exceptionhandling vor 20 Jahren in Windows noch nicht gab und was einmal eingeführt wurde muss der lieben Kompatibilität auch so bleiben.
Aber ich kann mindestens ein Dutzend Posts aus der DP auflisten, wo Programmierer WinAPI Aufrufe machen und den Rückgabewert (geschweige denn GetLastError) überhaupt garnicht beachten. Und dann gibt es noch abertausende WinAPI Beispielquelltexte sogenannter Experten, die keinerlei Fehlerüberprüfung besitzen.
Deshalb nutze ich ja Exceptions, weil es die lauten Nachkommen der "if error then" Mutter sind. Wenn eine Exception geworfen wird, dann bekommt das der Programmierer mit, wenn er nicht seinen Quelltext mit häßlichen try..except Blöcken zubaut. Eine geworfene Exception springt dem Programmierer ins Gesicht, so dass er sie nicht ignorieren kann. Das ist doch das Schöne daran!

Zitat:

Ein Fehlercode ist ja "nur" ein detailierterer Boolean (erfolgreich, nichterfolgreich+warum).
...
Es gäbe praktisch keine Funktionen mehr, sondern fast nur noch Prozeduren und eine Edit.IsReadOnly würde als Ergebnis eine Exception werfen, wenn es nicht schreibgeschützt ist.

Genau das sollte es nach meiner Meinung aber so sein. In der JWSCL gibt es praktisch auch keine Funktion mehr. Nur Funktionen mit Rückgabewerten, die ein Resultat zurückliefern. Fehler werden ausschließlich mit Exceptions geworfen.

Aber an deinem letzten Satz sehe ich, dass du nicht verstanden hast, was Exceptions sind. Denn Exceptions werden nicht für den normalen Ablauf verwendet. Damit werden keine Ergebnisse zurückgeliefert, sondern nur Ausnahmesituationen, die man als Fehler interpretieren kann (unbekannte Fehler werden dabei an den eigenen Aufrufer übergeben, der Rest wird behandelt = Exceptions).
Damit kann man bei einer ReadOnly-Eigenschaft, den Wert False nicht als einen Fehler interpretieren. Die Eigenschaft hat zwei Rückgabewerte (True/False) und viele andere mögliche Fehlerausgänge. Und das sind eben keine ReadOnly-Ergebnisse. Stattdessen wirft man hier Exceptions, wovon z.B. eine aussagt, dass eine Eigenschaft schreibgeschützt ist.
Deshalb haben Exceptions ja sogut wie keinen Einfluss auf die Ablaufgeschwindigkeit des normalen Programmcodes (Dr.Bob), wie soviele fürchten.


Mit Exceptions ist auch der ganze Aufwand mit den Mapping von Fehlercodes in Fehlertexte überflüssig geworden. Stattdessen schreibt man den Fehlertext in die Exception. Das hat auch noch den großen Vorteil, dass man den Text einfach der Situation anpassen kann und z.B. Werte für das Debugging hineinschreibt.

raise EMyException.CreateFmt('Invalid Parameter %s. Allowed values are %d...%d', ['Parameter1', 1, 100]); Das wäre nämlich bei der C WinAPI von großen Vorteil, da der Fehler ERROR_INVALID_PARAMETER sehr verhasst ist bei Funktionen mit mehreren oder komplizierten Parametern. Eigentlich kann er nämlich alles mögliche bedeuten.

• Der Wert eines Parameter ist korrekt.
• Der Zeiger auf einen Zeiger eines Parameter ist korrekt.
• Ein Parameter darf nicht nil sein
• Ein Parameter muss nil sein.
• Die Größe eine Struktur ist inkorrekt.
• Die Struktur wurde inkorrekt initialisiert.
• Ein Parameter kann nicht zusammen mit einem anderen Parameter verwendet werden.
• Ein Statuswert ist inkorrekt (meist inkorrekte Statusbitfolge)
• Ein Statusflag ist gesetzt, aber der zugehörige Parameter ist inkorrekt.
• ... und sicherlich noch einige mehr, die ich vergessen habe.

Nach Definition sind alle Ausgabewerte einer WinAPI Funktion unberührt, wenn ein Fehler auftritt. Wenn aber Fehler nicht abgefangen sind, dann ist es oftmals "normal", dass man mit diesen Werte arbeitet. Nunja, selber Schuld könnte man sagen. Ich sage aber, dass das mit Exceptions nicht passieren kann, wenn man nicht mit voller Absicht handelt.

Daher nutze ich beim Aufruf immer ersteinmal:

Delphi-Quellcode:

if not XY then
  raiseLastOsError;