eigene Fehlercodes als Rückgabewert definieren

[Gargamel]

Hi

Ich möchte gerne eigene Fehlercodes für meine Funktionen definieren. Blöd ist halt, daß Funktionen selbst ja einen Wert zurückliefern und somit kein Platz für Fehlercodes ist. Um das zu umgehen, dachte ich mir, einfach jeder Funktion noch einen Zeiger mitzugeben, den ich nach der Beendigung der Funktion auslese, um so an die Fehlercodes zu gelangen. Jetzt hätte ich gerne gewußt, ob so eine Vorgehensweise in Ordnung ist oder es evtl. noch andere Möglichkeiten gibt.
Ich zeige Euch mal den Quellcode. (der funktioniert übrigens recht gut)

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  recErrorCode = record
    ECode:integer;
    desc:string;
  end;
  PErrorCode = ^recErrorCode;

  TForm1 = class(TForm)
    Button1: TButton;
    Label1: TLabel;
    Label2: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

  TSchnulli = class(TObject)
    strict private
      Pinselei:TStringList;
      Pinselei2:TStringList;
    public
      constructor create();
      destructor destroy;
      procedure addText(text:string;var ECode:PErrorCode);
      function getText(index:integer; var ECode:PErrorCode):string;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

constructor TSchnulli.create;
begin
  Pinselei:=TStringList.Create;
  Pinselei2:=TStringList.Create;
end;

destructor TSchnulli.Destroy;
begin
  FreeAndNil(Pinselei);
  FreeAndNil(Pinselei2);
end;

procedure TSchnulli.addText(text:string; var ECode:PErrorCode);
Begin
  Pinselei.Add(text);
  ECode.ECode:=0;
  ECode.desc:='Fein, hat alles geklappt.';
End;

function TSchnulli.getText(index:integer; var ECode:PErrorCode):string;
var erg:string;
Begin
  erg:='';
  if index < Pinselei.Count then
  Begin
    erg:=Pinselei.Strings[index];
    ECode.ECode:=0;
    ECode.desc:='Sehr schick.';
  End
  else
  Begin
    ECode.ECode:=27;
    ECode.desc:='Index ist zu hoch. Die Zeile ist doch garnicht da. :-(';
  End;

  result:=erg;
End;

procedure TForm1.Button1Click(Sender: TObject);
var bla:TSchnulli;
    ECode:PErrorCode;
    text:string;
Begin
  bla:=TSchnulli.create;

  // Text einfügen
  new(ECode);
  bla.addText('Butzibär',ECode);
  Label1.Caption:='ErrorCode: '+inttoStr(ECode.ECode) + ' *** ErrorDesc: '+ECode.desc;
  dispose(ECode);

  // Text auslesen
  new(ECode);
  text:=bla.getText(1,ECode);
  Label2.Caption:='ErrorCode: '+inttoStr(ECode.ECode) + ' *** ErrorDesc: '+ECode.desc;
  dispose(ECode);

  button1.Caption:=text;

  FreeAndNil(bla);
end;

end.

[DeddyH]

Wieso programmierst Du nicht so etwas wie GetLastError nach? Du deklarierst Deinen Record einfach als Feld von TSchnulli und befüllst ihn im Fehlerfall dort. Willst Du ihn auswerten, kannst Du das dann an zentraler Stelle tun.

[Iwo Asnet]

Und wieso nicht einfach mit Exceptions arbeiten? Fehlercodes sind doch Schrott.

[Gargamel]

Zitat:

Wieso programmierst Du nicht so etwas wie GetLastError nach? Du deklarierst Deinen Record einfach als Feld von TSchnulli und befüllst ihn im Fehlerfall dort. Willst Du ihn auswerten, kannst Du das dann an zentraler Stelle tun.

Weil ich einige Funktionen u.U. via Multithreading laufen lassen will und ich mir nicht sicher bin, ob es da u.U. Überschneidungen gibt. (GetLastError).

Zitat:

Und wieso nicht einfach mit Exceptions arbeiten? Fehlercodes sind doch Schrott.

Ich finde ErrorCodes ganz nett.

[shmia]

Zitat:

Zitat von Gargamel (Beitrag 1110106)

Ich finde ErrorCodes ganz nett.

Das sagst du nur, weil du das Prinzip der Exceptions nicht in voller Tiefe verstanden hast.
*ALLE* modernen Programmiersprachen setzen auf Exceptions weil es einfach der bessere Weg ist mit Fehlern zur Laufzeit umzugehen.

Delphi Kurs - Exceptions
Exceptions Tutorial

[FredlFesl]

Beispiel 1:

Delphi-Quellcode:

Prozedur1(xy,ErrorCode);
if ErrorCode = Prozedur1WarOK then begin
  Prozedur2(xy,ErrorCode);
  if ErrorCode = Prozedur2WarOK then begin
    Prozedur3(xy,ErrorCode);
    if ErrorCode = Prozedur3WarOK then
       ShowMessage('Funzt')
    else
       Fehlerbehandlung(ErrorCode); 
    end
  else
    Fehlerbehandlung(ErrorCode);
end
else
  Fehlerbehandlung(ErrorCode);

Beispiel 2:

Delphi-Quellcode:

Try
  Prozedur1(xy);
  Prozedur2(xy);
  Prozedur3(xy);
  ShowMessage('Funzt')
Except
  On E:Exception Do 
    Fehlerbehandlung(E);
End;

1. Welcher Code ist übersichtlicher?
2. Welcher Code ist leichter zu verändern?
3. Welcher Code ist verständlicher?

[SirThornberry]

@Gargamel:
An sich ist es schon richtig wie du es machst. Allerdings ist es unüblich den Fehlercode über var/out Parameter zurück zu liefern und das Ergebnis per result.
In der Regel wird es genau umgekehrt gemacht. Denn was soll die Funktion zurück geben wenn ein Fehler aufgetreten ist?
Zudem lässt sich bei Fehlercodes per Result einiges etwas kürzer schreiben:

Delphi-Quellcode:

if FunktionsAufruf(Ergebnis) = RES_SUCCESS then
  DoAnything;

Zitat:

Zitat von shmia (Beitrag 1110110)

Zitat:

Zitat von Gargamel (Beitrag 1110106)

Ich finde ErrorCodes ganz nett.

Das sagst du nur, weil du das Prinzip der Exceptions nicht in voller Tiefe verstanden hast.
*ALLE* modernen Programmiersprachen setzen auf Exceptions weil es einfach der bessere Weg ist mit Fehlern zur Laufzeit umzugehen.

Delphi Kurs - Exceptions
Exceptions Tutorial

Wenn ich mir die WinApi anschaue ist da überhaupt nichts mit Exceptions zu finden. Auch so ist es quatsch ressourcenintensive Exceptions zu werfen wenn man auch ohne diese auskommt.
Stell dir vor StrToIntDef etc. würden mit Exceptions arbeiten, und durch abfangen dieser das Ergebnis zurück liefern. Man hätte ganz viel Spaß beim debuggen und langamer wäre das ganze auch.

@FredlFesl: schlechtes Beispiel.
Es ginge auch so:

Delphi-Quellcode:

if Funktion1(aRes) and Funktion2(aRes) and Funktion3(aRes) then
  showmessage('success')
else
  showmessage(ErrCodeToString(aRes));

oder wenn die Funktion per result den Fehler zurück gibt:

Delphi-Quellcode:

function CheckOK(aRes: Integer; out atErr): boolean;
begin
  result := true;
  if aRes <> RES_SUCCESS then
  begin
    aLastErr := aErr;
  end;
end;

procedure Test;
var
  lErr: Integer;
begin
  if CheckOk(Funktion1(aRes),lErr)
    and CheckOk(Funktion2(aRes),lErr)
    and CheckOk(Funktion3(aRes),lErr) then
    showmessage('success')
  else
    showmessage(ErrCodeToString(lErr));

[shmia]

Zitat:

Zitat von SirThornberry (Beitrag 1110123)

Wenn ich mir die WinApi anschaue ist da überhaupt nichts mit Exceptions zu finden.

Ist ja logisch, weil das Konzept der Exceptions zur Zeitpunkt der Windows Entwicklung bei Microsoft noch nicht Stand der Technik war.
Im .NET Framework sind Exceptions aber von Anfang an etabliert.
Dort werden sogar verschachtelte Exception unterstützt was Delphi leider bislang noch fehlt.

Zitat:

Zitat von SirThornberry (Beitrag 1110123)

Auch so ist es quatsch ressourcenintensive Exceptions zu werfen wenn man auch ohne diese auskommt

Nur weil eine bestimmte Technik mehr Resourcen benötigt als eine Andere kann man sie noch lange nicht als "Quatsch" bezeichnen.
Es kommt eben auch immer auf die Abstraktionsebene an auf der man sich bewegt.
In einem Treiber oder einer normalen DLL möchte man sicher keine Exceptions nach aussen geben.
Bei einer Active-X DLL oder einer ganz normalen Delphi-Anwendung sieht die Sache schon ganz anderst aus.

[Gargamel]

Da hier gerade die Begriffe DLL und Delphi-Anwendung fielen: Ich hätte evtl. erwähnen sollen, daß der Code tatsächlich in eine DLL soll. Sorry, war mein Fehler.

[shmia]

Zitat:

Zitat von Gargamel (Beitrag 1110135)

Ich hätte evtl. erwähnen sollen, daß der Code tatsächlich in eine DLL soll.

In diesem Fall musst du aber auf Objektorientierung an der Nahtstelle zwischen der DLL und der Anwendung verzichten!
Wenn du ganz "stinknormale" Funktionen in deiner DLL hast wie z.B.

Delphi-Quellcode:

function MachWas(inparam1:integer; var ergparam:PChar):integer; Stdcall;

dann ist es üblich den Fehlercode als Result zurückzugeben.
Wenn du aber mit Objekten und Klassen arbeiten willst, dann kommst du mit einer normalen DLL nicht weiter.