Verständnisfrage zu Exit

[venice2]

Zitat:

Jetzt habe ich mich ein bisschen ereifert, da bitte ich um Nachsicht.

Kein Problem nur warum überhaupt ein "begin"

Delphi-Quellcode:

If Bedingung1 then
  exit
else if Bedingung2 then 
  Mache2
else if Bedingung3 then 
  Mach3
else 
...

zudem würde ich solche Verschachtelungen gar nicht verwenden sondern direkt mit Case arbeiten.

Delphi-Quellcode:

case Bedingung of
  1:
    exit;
  2:
    Mache2;
  3:
    Mache3;
  else
    was auch immer
end;

[HeZa]

Zitat von venice2:

Kein Problem nur warum überhaupt ein "begin"

Da bin ich bei dir. Zur Not könnte man den Code aus den begin-end Blöcken in kleine lokale Proceduren/Funktionen packen.

Zitat von venice2:

zudem würde ich solche Verschachtelungen gar nicht verwenden sondern direkt mit Case arbeiten.

Da es unterschiedliche Bedingungen sein könnten, ist ein case nicht immer möglich.

[mkinzler]

Zitat:

Ich finde die Methode 2 weder böses GoTo noch Spaghetticode oder sonstwas, sondern nur eins: Sehr übersichtlich.

Ich bevorzuge eher begin und end auf selber (Einrückungs-)Ebene.

Zitat:

Kein Problem nur warum überhaupt ein "begin"

Damit man es nicht später vergisst. (wenn dann die Sequenz erweitert wird)

Zitat:

Zur Not könnte man den Code aus den begin-end Blöcken in kleine lokale Proceduren/Funktionen packen.

Warum nur zur Not? Hängt eher vom Unfang/Länge der Sequenz( Block) ab und ob er vielleicht wo anders noch benötigt wird.

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

[bcvs]

Zitat von dummzeuch:

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;

Genau für diesen Fall verwende ich Exit auch ganz gerne. Auch weil es eine Einrückungsebene spart. Die Alternative wäre ja:

Delphi-Quellcode:

procedure bla(const _s: string);
begin
  if _s <> '' then begin
    // irgendwas längeres mit _s machen
  end;
end;

[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?