Verständnisfrage zu Exit

[dummzeuch]

Juchu, lasst uns noch eine Diskussion um Goto und Goto-ähnliche Konstrukte führen! Das hatten wir schon lange nicht mehr.

Meine Meinung:
Im Gegensatz zu Continue, Break und einem Goto, ist Exit ein relativ harmloses Konstrukt und hat definitiv seine Anwendung. Insbesondere verwende ich es gern, um am Anfang einer Methode die Eingangs-Voraussetzungen (Parameter, Zustand des Objekts) zu prüfen und die Methode dann zu verlassen, wenn es nichts zu tun gibt.

Delphi-Quellcode:

procedure bla(const _s: string);
begin
  if _s = '' then begin
    // ein leerer String braucht nicht verarbetet zu werden.
    Exit; //==>
  end;
  // irgendwas längeres mit _s machen
end;

oder

Delphi-Quellcode:

procedure TSomeObject.SetVisibiel(_Value: boolean);
begin
  if _Value = FVisible then begin
    // keine Änderung -> raus
    Exit; //==>
  end;

  FVisible := _Value;
  // jetzt noch alles mögliche andere machen
end;

Dieses "Early Return" wird durchaus häufig verwendet, ist aber nicht ganz umstritten.

Dann gibt es noch eine andere praktische Verwendung von Exit: Das frühzeitige Verlassen von Schleifen:

Delphi-Quellcode:

function FindMatchingString(_sl: TStringList; const _s: string; out _Idx: Integer): boolean;
var
  i: Integer;
begin
  for i := 0 to _sl.Count -1 do begin
    if StartsText(_s, _sl[i]) then begin
      _Idx := i;
      Result := True;
      Exit; //==>
    end;
  end;
  Result := False;
end;

Natürlich könnte man da auch Break verwenden, aber die Erfahrung hat mich gelehrt, dass ein Break gerne mal nicht die Schleife beendet, von der man denkt, dass sie beendet wird. Nachdem ich zum x-ten Mal irgendo eine geschachtelte Schleife eingebaut hatte und Break dann plötzlich nur noch diese innere Schleife verlasen hat, habe ich mir komplett abgweöhnt, es zu verwenden. Dito Continue.

Ach ja, und dann gibt es da immernoch das einzige Goto in unserer Codebase, das ich vor 13 Jahren eingebaut habe und jetzt schon aus Trotz drin lassen werde.

[Medium]

Zitat von dummzeuch:

Delphi-Quellcode:

function FindMatchingString(_sl: TStringList; const _s: string; out _Idx: Integer): boolean;
var
  i: Integer;
begin
  for i := 0 to _sl.Count -1 do begin
    if StartsText(_s, _sl[i]) then begin
      _Idx := i;
      Result := True;
      Exit; //==>
    end;
  end;
  Result := False;
end;

Da sollte dir der Compiler um die Ohren hauen, dass das Funktionsergebnis undefiniert sein kann. Setze das Result := false; an den Anfang der Funktion, und sie ist okay.

Dennoch finde ich GERADE hier Exit sau gefährlich! Da muss nur einer mal auf die Idee kommen, noch Code hinter die Schleife zu packen, der auf jeden Fall durchlaufen werden soll.

Continue und Break haben sich bei mir bisher immer brav verhalten. Was unheimlich hilft dabei, ist es die Schleifenrümpfe brav alle in begin..end Blöcke zu verpacken, sodass der Scope immer eindeutig ist - auch optisch.

[Uwe Raabe]

Zitat von Medium:

Da sollte dir der Compiler um die Ohren hauen, dass das Funktionsergebnis undefiniert sein kann.

Wieso? Ich sehe da keinen möglichen Code-Path, der die Funktion ohne Setzen von Result verlässt.

[Medium]

Zitat von Uwe Raabe:

Zitat von Medium:

Da sollte dir der Compiler um die Ohren hauen, dass das Funktionsergebnis undefiniert sein kann.

Wieso? Ich sehe da keinen möglichen Code-Path, der die Funktion ohne Setzen von Result verlässt.

Oh, du hast Recht. Vor dem Exit MUSS ja result := true passieren. Mea culpa. Dennoch finde ich es unschön in diesem Fall.

[DasWolf]

Zitat von Medium:

Setze das Result := false; an den Anfang der Funktion, und sie ist okay.

Nein, Nein, Nein und nochmal Nein. Das Result wird nicht am Anfang belegt.

[Medium]

Warum das denn?

[DasWolf]

Zitat von Medium:

Warum das denn?

Alt, aber da halte ich mich immer noch dran: https://www.delphipraxis.net/85402-post.html#93878

[Uwe Raabe]

Zitat von DasWolf:

Alt, aber da halte ich mich immer noch dran: https://www.delphipraxis.net/85402-post.html#93878

Ich denke, da geht es eher darum das Result als lokale Variable zu missbrauchen. Das hat aber eher was mit Performance zu tun als mit gutem oder schlechtem Programmierstil.

[himitsu]

Zitat von Uwe Raabe:

Ich denke, da geht es eher darum das Result als lokale Variable zu missbrauchen. Das hat aber eher was mit Performance zu tun als mit gutem oder schlechtem Programmierstil.

Ich sehe das sogar eher andersrum.

Empfinde es schlecht hässlich, wenn man sinnlos eine weitere Variable benutzt, anstatt direkt Result.

Und von der Preformance her ist das kein Unterschied.
Es kann sogar sein, dass die zusätzliche Variable mehr speicher benötgt, wenn es für den Compiler nicht möglich ist, die Resultvariable (deren Speicherplatz) erst ab der Stelle der Zuweisung zu reservieren.


Es gibt aber Einwas, wo man das als Nachteil betrachten könnte.
Denn z.B. ein Result als Interface oder String, wird vom Compiler als VAR-Parameter behandelt.
Kommt es dann zu einer Exception, dann würde die äußere Variable (da wo das Result der Funktion zugewiesen werden sollte) bereits verändert sein, was man so nicht direkt erwarten würde.

Delphi-Quellcode:

function MyFunc: string;
begin
  Result := '2';
  raise Exception.Create('');
end;

procedure Test;
var
  X: string;
begin
  X := '1';
  try
    X := MyFunc;
  except
    ShowMessage(X);
  end;
end;

Das selbe Beispiel mit Integer als Variable/Result, da bleibt es "1", da an "X" ja noch nchts zugewiesen wurde, weil es "vorher" abgeraucht ist.

Für mich sind nach einer Exception Results von jeglichen Funktionen sowieso als "ungültig" anzusehen, somit gibt es IMHO damit eigentlich auch keine Probleme.

[stahli]

Zitat von DasWolf:

Nein, Nein, Nein und nochmal Nein. Das Result wird nicht am Anfang belegt.

Die Zuweisung am Anfang zu erzwingen ist genau so Unsinn wie das zu verweigern.
Es kommt doch immer auf den Einzelfall an. Darüber hinaus spielen dann auch noch persönliche Vorlieben oder Vorgaben in einer Firma hinein.

Darüber zu streiten macht keinen Sinn.