![]() |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
TConfigError und TDBError z.B.
|
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
Achso, ja ok.
Ich danke euch! |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
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
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 ![]() ![]() ![]() Dann kannst du eigene Fehlermeldungen z.B. mit SetLastError setzen bzw direkt zurückgeben. Dazu kannst du ![]() 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:
Leider kann man das Customerbit damit nicht setzen, deshalb so:
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;
Delphi-Quellcode:
Natürlich wäre ich begeistert, wenn du das so machen würdest und diese Idee auf dem
Error := Error or $20000000;
![]() |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
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. ;) |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
Wenn du eigene Fehlercodes z.B. über
![]() ![]() Es gibt dort einen nur gewissen Bereich, welchen du verwenden dürftest, außerdem gibt es für diese Codes ein festgelegtes Format. |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
Zitat:
Zitat:
Daher zwei mögliche Wege. 1. HRESULT als Rückgabewert nutzen:
Delphi-Quellcode:
2. SetLastError nutzen
function MyFunc(...) : HRESULT;
begin result := MakeResult(1, 100, MY_ERROR) or $20000000; end;
Delphi-Quellcode:
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.
function MyFunc(...) : Boolean;
begin //fehler SetLastError(MakeResult(1, 100, MY_ERROR) or $20000000); result := false; end; Zitat:
|
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
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 |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
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:
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. |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
Zitat:
Aber soviel Aufwand ist garnicht nötig, solange man nur seine eigenen Fehlerpfade definiert und dokumentiert. Siehe JWSCL. Zitat:
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:
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:
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.
raise EMyException.CreateFmt('Invalid Parameter %s. Allowed values are %d...%d', ['Parameter1', 1, 100]);
Daher nutze ich beim Aufruf immer ersteinmal:
Delphi-Quellcode:
if not XY then
raiseLastOsError; |
Re: Eigene Fehlercodes / Fehlermeldungen erstellen/verwalten
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz