eigene Fehlercodes als Rückgabewert definieren

[shmia]

Zitat von Gargamel:

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 von shmia:

Zitat von Gargamel:

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 von SirThornberry:

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 von SirThornberry:

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 von Gargamel:

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

[Gargamel]

Die Klassen arbeiten nur innerhalb der DLL. Die Kommunikation zwischen Anwendung und DLL erfolgt über ganz normale Funktionen.

[FredlFesl]

Zitat von SirThornberry:

@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));

Das ist keine Äquivalenzumformung meines Beispielcodes, also ginge es *NICHT* so.
Gegenfrage:
-In welcher Reihenfolge werden die Funktionen aufgerufen? (links nach rechts? rechts nach links?)
-Werden alle Funktionen aufgerufen? (Stichwort: Compilerschalter)

Beispiel für ein schlechtes Beispiel gefällig?
Code, dessen Funktionsweise von Compilerschaltern und der Sprachenphilosophie abhängt!

Sechs, setzen.

Na, sagen wir: Vier miiinus.

[SirThornberry]

Die Funktionen werden von Links nach Rechts aufgerufen.
Und ja, das ganze ist vom Compilerschalter abhängig. Ebenso wie viele Funktionen in der Unit SysUtils.
Somit ist das ganze an einen Compilerschalter gebunden der nahezu immer notwendig ist.
Ich würde es auch nicht generell verurteilen Quelltext an Compilerschalter anzupassen. Ich würde das eher Optimierung nennen.
Zum Beispiel knallt folgender Quelltext bei einem Leerstring wenn die Bereichsprüfung an ist weil angeblich auf Index 1 des Strings zugegriffen wird (was durch die Lengthangabe aber nicht stört)
move(LeerString[1], MyBuffer[0], Length(LeerString)); Jetzt könnte man da eine Prüfung der Länge davor setzen aber warum eine zusätzliche Anweisung einbauen die bei einem selbst nicht notwendig ist.

Also bitte keine 4- sondern eine 3+

[sirius]

Wenn du über DLL-Grenzen hinwegarbeitest bietet sich die Aufrufkonvention "SafeCall" an. SafeCall gibt immer zusätzlich zum eigentlichen Rückgabewert einen zweiten Rückgabewert vom Typ HResult mit. Und die Logik dahinter macht Delphi automatisch,

Ich hab grad kein Delphi hier um das nochmal zu testen, aber folgendes sollte funktionieren (auch über DLL-Grenzen hinweg):

Delphi-Quellcode:

//in DLL
function myDiv(a,b:Integer):Integer;safecall;
begin
  if b<>0 then
    result:=a div b
  else
    raise Exception.create('Du Idiot, wenn man durch null teilt, landet man beim schwarzen Mann.');
end;



//in Exe
function mydiv(a,b:Integer):Integer; safecall; 
  external myDLL;

begin
  try
    mydiv(4,0);
  except
    on E:Exception do
      showmessage(e.MEssage); //ich glaube Delphi kriegt die Message nicht wirklich durch, aber schau mal.
  end;
end.

Mit SafeCall kannst du auch deine eigenen Fehlercodes mitgeben. Aber dazu bräuchte ich jetzt doch mal ein Delphi.
Es müsste in etwa so gehen:

Delphi-Quellcode:

//in DLL
function myDiv(a,b:Integer;out res:Integer):HResult;stdcall; //dies entspricht derselben Aufrufkonvetnion wie oben
begin
  if b<>0 then
  begin
    res:=a div b;
    result:=s_ok;
  end else
  begin
    res:=0; //ist egal
    result:=-80; // lustiger Fehlercode, muss negativ sein (bzw. MSB muss gesetzt sein)
  end;
end;

//der Exe-Teil sollte genau gleich aussehen (auch mit safecall)
//die Exception wirft das Hauptprogramm automatisch, wenn der Fehlercode bestimmte Werte annimmt, ich hoffe die 80 reicht dazu.

Edit: Korrektur: Fehlercode muss negativ sein.
Als Ergänzung kannst du in der Exe, sofern du kein ActiveX nutzt (also unit comobj nicht einbindest), die globalew Variable SafeCallErrorProc umsetzen:

Delphi-Quellcode:

procedure SafeCallError(ErrorCode: Integer; ErrorAddr: Pointer);
var adr:Pointer;
begin
  raise Exception.Create('Fehlercode' + inttostr(ErrorCode) );
end;

initialization
SafeCallErrorProc:=@SafeCallError;