Funktion ohne Result?

[fkerber]

Hi!

Ich habe folgende Funktion:

Delphi-Quellcode:

function DeleteUser(user: String): Boolean;
var
 Identities: TIniFile;
begin
 result:=False;          // <--------
 Identities:=TIniFile.Create(ExtractFilePath(paramstr(0))+'\Identities.dat');
 Try
   Identities.EraseSection(user);
   Result:=True;
 Finally
   Identities.Free;
 end;
end;

Die markierte Zeile wird manchmal nicht mitkompiliert (dieser blaue Punkt am Rand fehlt) oder es kommt dann ein Hint im Sinne von ("Der Wert DeleteUser wird nie benutzt").
Ich rufe die Funktion in einer If-Abfrage auf. Wenn jetzt also der Zugriff auf die Ini fehlschlägt dann sollte das Result eigentlich False sein. Nur wie soll das sein, wenn die Zeile gar nicht mitkompiliert wird?
Ich kann die Zeile auch rauslöschen. Da hätte ich jetzt eher ne Warnung wie "Funktionsresult könnte undefiniert sein" erwartet.

Habe ich irgendwo nen Denkfehler?

Ciao Frederic

[himitsu]

Also eigentlich denkst du richtig ... denke ich mal


Du könnest ja auch andersrum versuchen - mit Except, das sollte auch gehn:

Delphi-Quellcode:

function DeleteUser(user: String): Boolean; 
var 
Identities: TIniFile; 
begin 
Result:=True; 
Identities:=TIniFile.Create(ExtractFilePath(paramstr(0))+'\Identities.dat'); 
Try 
   Identities.EraseSection(user); 
Except
   Result:=False;         
end; 
Identities.Free; 
end;

Man könnte auch mal die Code-Optimierung (teilweise) abstellen:

Delphi-Quellcode:

...
begin
{$O-} Result:=False; {$O+}
Identities:=TIniFile.Create(ExtractFilePath(paramstr(0))+'\Identities.dat');
...

[fkerber]

Hi!

Ja, das geht sicherlich auch, aber es interessiert mich in erster Linie auch, warum das so passiert. Im Prinzip macht der Compiler da ja nen Fehler rein, oder?

Ciao Frederic

[himitsu]

Ich denk mal, es ist ein Fehler in der Code-Optimierung ... so wie es aussieht geht die davon aus, das alles zwischen Try und Finally ausgeführt wird.

- Wenn ich Result:=True; (in Try/Finally) wegnehme, dann wird das Result:=False; ja mitkompiliert.

[fkerber]

Hi!

Ja, aber er kann ja nicht davon ausgehen, dass derTry erfolgreich ausgeführt wird, oder?
Was passiert, wenn nicht?

Ciao Frederic

[SirThornberry]

Ist eindeutig ein Fehler in der Codeoptimierung, den bei Try-Except functionierts ja (zumindest als ich das benutzt hab)

[himitsu]

Na dann scheuchen wir mal die Daniels auf ... die haben doch so gute Beziehungen zu Borland ... dann sollte der Fehler ja bis nächste Woche behoben sein

[Christian Seehase]

Moin Frederic,

Zitat von fkerber:

Im Prinzip macht der Compiler da ja nen Fehler rein, oder?

eigentlich nicht.

Der Try-Abschnitt wird, bei normalem Programmablauf, immer durchlaufen, und somit Result dort gesetzt.
Es spielt hierbei auch keine Rolle, ob es sich nun um einen Try/Finally oder einen Try/Except Block handelt.

Da Result nur im Fehlerfalle auf false stehen soll, müsstest Du es so machen, wie Himitsu es vorgeschlagen hat.
Ich würde hier allerdings auch noch einen try/finally Block ergänzen, damit auch im Falle eines Fehlers das Inifile-Objekt wieder freigegeben wird.

Delphi-Quellcode:

function DeleteUser(user: String): Boolean;

var
  Identities: TIniFile;

begin
  Result:=True;
  Identities:=TIniFile.Create(ExtractFilePath(paramstr(0))+'\Identities.dat');
  try
    Try
      Identities.EraseSection(user);
    Except
      Result:=False;         
    end;
  finally
    Identities.Free;
  end;
end;

[fkerber]

Hi!

Das ist dann schlecht
Dann muss ich wohl umbauen.

ciao Frederic

[fkerber]

Hi!

@Sakura:
Ich dachte der Try-Block wird verlassen, wenn das Erase fehlschlägt. Ist das nicht der Fall?

Ciao Frederic