Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten

[DeddyH]

TConfigError und TDBError z.B.

[TheMiller]

Achso, ja ok.

Ich danke euch!

[Dezipaitor]

Also ersteinmal würde ich Fehlermeldungen, die von Funktionen zurückegeben werden, nicht in Delphi verwenden. Dafür gibt es Exceptions, die ganz einfach einen String als Meldung bekommen, so dass du siehst, was passiert.
Aus meiner Erfahrung kann ich sagen, dass Programmierer gerne das Prüfen der Rückgabewerte vergessen und dann merkwürdige Ergebnisse bekommen.

Als Außnahme lasse ich gelten, wenn

• die Funktionen sehr, sehr oft aufgerufen werden soll und genauso oft einen Fehler melden muss (sehr selten). Exceptions verlangsamen den Aufruf nur dann, wenn sie ständig geworfen werden, nicht jedoch, wenn der reguläre Ausführungspfad durchgeführt wird. Siehe Kaptitel Exceptions bei Dr. Bob.
• die Funktionen in eine DLL gepackt werden sollen und damit von anderen Sprachen verwendet werden.

Du kannst von der Klasse Exception, einfach neue Fehlertypen ableiten, so wie das in der JWSCL gemacht wird.

Delphi-Quellcode:

EMyException = class(Exception);

Also, falls keine Exceptions verwendet werden sollen, so kannst du eigene Meldungen in einer Ressource, ähnlich der Stringresource, speichern, so dass auch verschiedene Sprachen möglich sind.

Windows verwendet dazu den Resourcentype MessageTable, den man ins Modul einbindet und mit FormatMessage und FORMAT_MESSAGE_FROM_HMODULE.

Dann kannst du eigene Fehlermeldungen z.B. mit SetLastError setzen bzw direkt zurückgeben. Dazu kannst du HRESULT verwenden, der es ermöglicht etwas flexibler zu sein. Deine Meldungscodes stecken dann im rechten Codefeld drin und können ohne Probleme bei 1 anfangen. Der Facilitycode ist eine ID, die angibt, welcher Bereich einer Software die Meldung erzeugt hat. So kann man dann herausfinden, dass eine Meldung von einem Funktionsaufruf innerhalb der aufgerufenen Methode stammt.
Setze außerdem das Custom Bit auf 1, damit es keine Verwechslung mit möglicherweise im SYSTEM vorhandenen Fehlercodes gibt.
Alle Werte >= 0 sind Erfolgsmeldungen, daher kann man auch extra Meldungen, wie z.B. "Aufruf erfolgreich, aber mehr Daten vorhanden." zurückliefern.

In ActiveX.pas gibt es einige Funktionen, die dir da helfen können.

Delphi-Quellcode:

function Succeeded(Res: HResult): Boolean; inline;
function Failed(Res: HResult): Boolean; inline;
function ResultCode(Res: HResult): Integer; inline;
function ResultFacility(Res: HResult): Integer; inline;
function ResultSeverity(Res: HResult): Integer; inline;
function MakeResult(Severity, Facility, Code: Integer): HResult; inline;

Leider kann man das Customerbit damit nicht setzen, deshalb so:

Delphi-Quellcode:

Error := Error or $20000000;

Natürlich wäre ich begeistert, wenn du das so machen würdest und diese Idee auf dem JEDI Blog veröffentlichen würdest (also eine Demoapp). Falls du Interesse hast, dann einfach bei mir melden. Unterstützung ist garantiert.

[TheMiller]

Das hört sich recht interessant an und ich bin nicht abgeneigt. Aber...: Bin ich dann von ActiveX abhängig?

So genau habe ich das jetzt nicht verstanden. ;)

[himitsu]

Wenn du eigene Fehlercodes z.B. über SetLastError (GetLastError) ausliefern willst, dann kannst du diese nicht einfach so vergeben ... (die 1 ist z.B. schon belegt)

Es gibt dort einen nur gewissen Bereich, welchen du verwenden dürftest, außerdem gibt es für diese Codes ein festgelegtes Format.

[Dezipaitor]

Zitat:

Zitat von himitsu

Wenn du eigene Fehlercodes z.B. über SetLastError (GetLastError) ausliefern willst, dann kannst du diese nicht einfach so vergeben ... (die 1 ist z.B. schon belegt)

Es gibt dort einen nur gewissen Bereich, welchen du verwenden dürftest, außerdem gibt es für diese Codes ein festgelegtes Format.

Okay, das stimmt natürlich. Deshalb nutzt man auch hier das 29te Bit, um damit keine Probleme zu haben:

Zitat:

Bit 29 is reserved for application-defined error codes; no system error code has this bit set.

Das gilt auch für HRESULT nur nutzt man da normal nicht SetLastError, was aber möglich wäre.

Daher zwei mögliche Wege.
1. HRESULT als Rückgabewert nutzen:

Delphi-Quellcode:

function MyFunc(...) : HRESULT;
begin
  result := MakeResult(1, 100, MY_ERROR) or $20000000;
end;

2. SetLastError nutzen

Delphi-Quellcode:

function MyFunc(...) : Boolean;
begin
  //fehler
  SetLastError(MakeResult(1, 100, MY_ERROR) or $20000000);
  result := false;
end;

Das sieht jetzt merkwürdig aus, weil normal bei GetLastError einer der ERROR_XXX (z.B. ERROR_FILE_NOT_FOUND) rauskommt. Aber der Autor der Funktion kann das selbst bestimmen.

Zitat:

Zitat von DJ-SPM

Das hört sich recht interessant an und ich bin nicht abgeneigt. Aber...: Bin ich dann von ActiveX abhängig?

So genau habe ich das jetzt nicht verstanden. ;)

Nein, das ist die Unit ActiveX.pas, worin diese Funktionen deklariert sind. D.h. nicht, dass du ActiveX verwendest. Du könntest diese Funktionen auch einfach rauskopieren oder selbst erstellen.

[Valle]

Hallo,

Also Dezipaitors Post hat mich schon sehr angesprochen. Ist es denn in herkömlichen Programmiersprachen ( = keine Scriptsprachen) immer noch üblich mit Rückgabewerten und Fehlercodes zu arbeiten? Oder dringen nicht mittlerweile auch die viel bequemeren und auch dafür gedacht Exceptions durch? So ist es bei modernen Programmiersprachen (d.h. Scriptsprachen in meinem Fall) schon etwas länger üblich. Ein try-except liest sich wesentlich logischer als irgendwelche Überprüfungen auf < 0 oder sowas. :-)

Liebe Grüße,
Valle

[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.

Ein Fehlercode ist ja "nur" ein detailierterer Boolean (erfolgreich, nichterfolgreich+warum).

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.


[add]

Zitat:

Oder dringen nicht mittlerweile auch die viel bequemeren und auch dafür gedacht Exceptions durch?

Stell dir mal vor das würde man wirklich konsequent durchsetzen.

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.

[Dezipaitor]

Zitat:

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.

Delphi-Quellcode:

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;

[himitsu]

Zitat:

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.

Eigentlich wollte ich damit auf eine komische Entwicklung hinweisen.
Hab es schon mehrmals gesehn, daß der Programmablauf via Exceptions gesteuert wurde und das ist ja auch nicht richtig.

Praktisch eine Exception statt einem Break oder Exit und dann ein blindes/leeres Try-Except drumrum.