"FinalllyExit" gewünscht

[FredlFesl]

Zitat:

Zitat von Stevie (Beitrag 1097882)

Ja, richtig, hier prallen wieder mal die unterschiedlichen Ansichtsweisen, was sauberer Code ist und was nicht, aufeinander. Ich stehe nach wie vor zu meiner Meinung und ich werde auch an irgendeiner Stelle wo es "nötig ist", von den 0.01% der Fälle Gebrauch machen und ein Exit einsetzen. Aber in keinem der hier im Thread erwähnten Fälle.

Du nimmst wirklich die 2.Variante? :shock:

Delphi-Quellcode:

// Total schlecht lesbarer und unsauberer Code mit EXIt
For i:=1 to N Do
  For j := 1 to M Do 
  Begin
    If Bla[i,j].HasInvalidData() Then Exit;
    Bla[i,j].Process();
    ...
  End;
...
//
...
// Suupersaubere Implementierung ohne EXIT. Toll!
i := 1; 
Aborted := False;
While (i <= N) and not Aborted Do 
Begin
  j := 1;
  While (j <= M) and Not Aborted Do 
  Begin
    If Bla[i,j].HasInvalidData() Then
      Aborted := True
    Else 
    Begin
      Bla[i,j].Process();
      ...
      Inc(J)
    End;
  End;
  Inc(i);
End;

[Stevie]

Zitat:

Zitat von FredlFesl (Beitrag 1097929)

Du nimmst wirklich die 2.Variante? :shock:

Nein, ich lagere die innere Schleife in eine extra Methode aus, wenn es nicht so geht, wie ich im vorherigen Post erwähnte.

[Namenloser]

Zitat:

Zitat von Stevie (Beitrag 1097931)

Zitat:

Zitat von FredlFesl (Beitrag 1097929)

Du nimmst wirklich die 2.Variante? :shock:

Nein, ich lagere die innere Schleife in eine extra Methode aus, wenn es nicht so geht, wie ich im vorherigen Post erwähnte.

Dann brauchst du in der äußeren aber immer noch ein break oder ein Abort-Flag.

[Stevie]

Break schlechter Programmierstil?

Wobei ich Break ehrlich gesagt öfter einsetze

[himitsu]

Im Prinzip sind das alles die selben Funktionalitäten
> "Abbrechen" aka unterbrechen des linearen Programmablaufs

If/Case > überspringen von Befehlen
Continue > einen Schleifendurchgang abbrechen
Break > ganze Schleife abbrechen
Exit > Funktion verlassen
Raise (Exception) > Thread beenden (es sei denn die Exception wird abgefangen > Try-Except)
Halt > Programm sofort beenden (ist voll unsauber und eher für schwerwiegende Poblembehandlungen geeignet)

(Goto könnte man bei mehreren dieser Punkte dazuschreiben)

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1097937)

Im Prinzip sind das alles die selben Funktionalitäten
> "Abbrechen" aka unterbrechen des linearen Programmablaufs

If/Case > überspringen von Befehlen
Continue > einen Schleifendurchgang abbrechen
Break > ganze Schleife abbrechen
Exit > Funktion verlassen
Raise (Exception) > Thread beenden (es sei denn die Exception wird abgefangen > Try-Except)
Halt > Programm sofort beenden (ist voll unsauber und eher für schwerwiegende Poblembehandlungen geeignet)

(Goto könnte man bei mehreren dieser Punkte dazuschreiben)

Und? Nur weils es gibt, isses auch gut?

Und nur, um es nochmal zu betonen, ich sage nicht, man darf das auf keinen Fall niemalsnich verwenden. Aber bereits das Code Beispiel im TE Post zeigte, dass dort Exit mal total falsch plaziert war. Man sollte die Verwendung auf ein absolutes Minumum reduzieren und nicht dort, wo man einfach nur nen Boolschen Ausdruck negieren könnte, nen Exit reindonnern.

[Aphton]

Die Existenz derer sagt, so wie du es schon angedeutet hast, nichts über ihr Nutzen (nützlich, gut, böse?) aus.
Es liegt alles am Programmierer.

Eigentlich sind wir hier alle in eine Tangente abgedriftet. Wäre nett, wenn man die Diskussion fortsetzen will, nen neuen Thread zu eröffnen!

[stahli]

Zitat:

Zitat von NamenLozer (Beitrag 1101760)

(anderer Thread)

Zitat:

Zitat von stahli (Beitrag 1101758)

- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel :wink:)

Ich glaube damit stehst du ziemlich allein. Warum sollte man das exakt selbe Feature doppelt implementieren? Bei den restlichen Punkten stimme ich dir aber weitestgehend zu.

Ich habe mal ein Testprojekt angehängt.
An den try-Blöcken stört mich die schlechte Debugbarkeit. Gerade habe ich einen Fehler gefunden, der in einer aufgerufenen Funktion auftrat. Durch den sch... try-Block war der schlechter lokalisierbar.
Ich mag die Dinger nicht und halte sie für wesentlich überschätzt.
Wenn man sie konsequent nutzen will, müsste man quasi jeden Befehl in einen try-Block kapseln.

Delphi-Quellcode:

A:=TA.Create;
B:=TB.Create;
try
  ...
finally
  A.Free;
  B.Free;
end;

Was aber, wenn schon TA.Create fehl schlägt???
Also müsste man dutzende try-Blöcke ineinander schachteln, um wirklich sicher zu sein?
Ich halte das für Unsinn.

In meinem Testprojekt kann man sehen, dass "end(normal)" nur in einem Fall aufgerufen wird.
Was ist aber bei 2 verschachtelten oder aufeinander folgenden try-Blöcken?

Ich halte ein Standardlabel "FinallyExit" für sehr sinnvoll, das einfach IMMER vor dem Verlassen einer Funktion/Prozedur angesprungen wird, egal was vorher auch immer passiert ist.
Sehr schwierig sollte das nicht lösbar sein, da ja weitestgehend nur die Exit-Sprungadresse geändert werden müsste.

PS: Das mit einem selbst definierten Label zu testen, wäre etwas umständlich, da man Exit(VALUE) so nicht (mit einer Anweisung) simulieren kann.

Delphi-Quellcode:

unit fTestFinallyExit;

interface

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

type
  TFormTestFinallyExit = class(TForm)
    ButtonTest: TButton;
    Memo: TMemo;
    RadioGroupMode: TRadioGroup;
    procedure RadioGroupModeClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    function Test: String;
  end;

var
  FormTestFinallyExit: TFormTestFinallyExit;

implementation

{$R *.dfm}

procedure TFormTestFinallyExit.RadioGroupModeClick(Sender: TObject);
begin
  Memo.Lines.Add('-----' + RadioGroupMode.Items[RadioGroupMode.ItemIndex] + '-----');
  Memo.Lines.Add(Test);
  Memo.Lines.Add('');
end;

function TFormTestFinallyExit.Test: String;
var
  S: String;
  I: Integer;

  procedure Add(SA: String);
  begin
    S := S + SA + #13#10;
  end;

begin
  Result := 'nix';
  S := '';
  I := 0;
  Add('begin');
  if RadioGroupMode.ItemIndex = 1 then
  begin
    Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
    Exit;
  end;
  if RadioGroupMode.ItemIndex = 2 then
  begin
    Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
    Exit('#');
  end;
  if RadioGroupMode.ItemIndex = 3 then
  begin
    Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
    Add(IntToStr(1 div I));
  end;
  try
    Add('  try');
    if RadioGroupMode.ItemIndex = 4 then
    begin
      Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
      Exit;
    end;
    if RadioGroupMode.ItemIndex = 5 then
    begin
      Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
      Exit('    #');
    end;
    if RadioGroupMode.ItemIndex = 6 then
    begin
      Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
      Add(IntToStr(1 div I)); // springt in finally und dann Exit ohne Result-Zuweisung
    end;
    Add('    ok');
  finally
    Add('  finally');
    Add('end(finally)');
    Result := S;
  end;
  Add('end(normal)');
  Result := S;
end;

end.

[omata]

Zitat:

Zitat von stahli (Beitrag 1101885)

Ich halte ein Standardlabel "FinallyExit" für sehr sinnvoll, das einfach IMMER vor dem Verlassen einer Funktion/Prozedur angesprungen wird, egal was vorher auch immer passiert ist.
Sehr schwierig sollte das nicht lösbar sein

Stimmt! Das ist überhaupt nicht schwer und muss auch nicht realisiert werden, weil es das gibt.

Delphi-Quellcode:

begin
  try
    // hier kommt alles rein
  finally
    // und das hier wird vor dem Verlassen ausgeführt, egal, was vorher war.
  end;
end;

Also worum gehts hier eigentlich. Alles da, was man braucht. Und deine tolle Idee ist nichts anderes und hat dann auch die selben Nachteile, die du hier vielleicht aufführen wirst.

Dabei gibt es gar keine Nachteile.

[Namenloser]

Ich sehe einfach nicht was der Vorteil von deinem FinallyExit sein soll. Was ist der Unterschied, ob ich schreibe

Delphi-Quellcode:

procedure Foobar;
begin
  try
    {…}
    if foo=bar then 
      Exit;
    {…}
  finally
    ShowMessage('foobar end')
  end;
end;

oder

Delphi-Quellcode:

procedure Foobar;
begin
  {…}
  if foo=bar then 
    Exit;
  {…}
  FinallyExit:
    ShowMessage('foobar end')
end;

?
Der einzige Unterschied, den ich sehe, ist, dass in letzterem Fall eine Zeile und eine Verschachtelung spare; aber dafür kommt ein zusätzliches, redundantes Sprachfeature hinzu.

Zitat:

Zitat von stahli (Beitrag 1101885)

Ich mag die Dinger nicht und halte sie für wesentlich überschätzt.
Wenn man sie konsequent nutzen will, müsste man quasi jeden Befehl in einen try-Block kapseln.

Delphi-Quellcode:

A:=TA.Create;
B:=TB.Create;
try
  ...
finally
  A.Free;
  B.Free;
end;

Was aber, wenn schon TA.Create fehl schlägt???
Also müsste man dutzende try-Blöcke ineinander schachteln, um wirklich sicher zu sein?
Ich halte das für Unsinn.

Dafür gibt es ein schönes Pattern:

Delphi-Quellcode:

A := nil;
B := nil;
try
  A := TA.Create;
  B := TB.Create;
finally
  A.Free;
  B.Free;
end;

Das Tolle an Free ist nämlich, dass erst geprüft wird, ob self nil ist:

Delphi-Quellcode:

procedure TObject.Free;
begin
  if Assigned(self) then
    Destroy;
end;

Abgesehen davon löst dein FinallyExit das von dir angesprochene Problem auch nicht.

Bezüglich deines Codebeispiels:
Wieso nicht einfach so?

Delphi-Quellcode:

function TFormTestFinallyExit.Test: String;
{…}
begin
  Result := 'nix';
  S := '';
  I := 0;
  Add('begin');
  {…}
  try
    Add(' try');
    {…}
    if RadioGroupMode.ItemIndex = 6 then
    begin
      Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
      Add(IntToStr(1 div I));
    end;
    Add(' ok');
  finally
    Add(' finally');
    Add('end(finally)');
    Result := S; // redundant
    Add('end(normal)');
    Result := S;
  end;
end;

oder so:

Delphi-Quellcode:

function TFormTestFinallyExit.Test: String;
{…}
begin
  try
    Result := 'nix';
    S := '';
    I := 0;
    Add('begin');
    {…}
    try
      Add(' try');
      {…}
      if RadioGroupMode.ItemIndex = 6 then
      begin
        Add(RadioGroupMode.Items[RadioGroupMode.ItemIndex]);
        Add(IntToStr(1 div I));
      end;
      Add(' ok');
    finally
      Add(' finally');
      Add('end(finally)');
      Result := S; // redundant
    end;
  finally
    Add('end(normal)');
    Result := S;
  end;
end;