Verständnisfrage zu Exit

[himitsu]

Zitat von Benmik:

Kann man ja wieder wegmachen, wenn das Debugging vorbei ist.

Ähhh neee?
Dann verhält sich dein Programm ja beim Debuggen womöglich anders, als in echt, was schon ein bissl sinnlos wäre.

Und natürlich geht es nur, wenn es eine Funktion und keine Prozedur ist. Und natürlich auch nur mit Boolean als Result.

[Benmik]

Nein, ich meinte doch Folgendes:

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  Result := False;
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  ....

Das "False" wäre ja nicht nötig, kann man zum Debuggen rein und hinterher wieder rausmachen.
(Oder man geht nach Hagen und macht das "Result := False" erst gar nicht hin, aber ich bin da gern auf der sicheren Seite.)

[bernau]

Zitat von Benmik:

Nein, ich meinte doch Folgendes:

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  Result := False;
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  ....

Das "False" wäre ja nicht nötig, kann man zum Debuggen rein und hinterher wieder rausmachen.
(Oder man geht nach Hagen und macht das "Result := False" erst gar nicht hin, aber ich bin da gern auf der sicheren Seite.)

In vielen Fällen spricht erst mal ja nichts dagegen, aus einer Procedure eine Function zu machen.

Das Result := False; kann man nach hinten verschieben.

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  Result := True;
  ....

Grade dein Procedurename/Funktionsname ist für ein Result geeignet. Laden des Jpeg hat funktioniert oder eben nicht.

[bernau]

Zitat von himitsu:

Und natürlich geht es nur, wenn es eine Funktion und keine Prozedur ist. Und natürlich auch nur mit Boolean als Result. :stupit:

Warum nur mit Boolean als Result?

[himitsu]

Weil das Exit(False) sonst knallt?

Und ja, diese Exit sind hier schon bissl blöd.
Es ist toll, wenn die Prozedur nicht nur Exit macht, sondern wenigstens noch Funktion noch ein False sagt,

aber erstmal wird oft genug vergessen das Result von Funktionen auszuwerten
und dann macht es die Fehlerbehandung und auch Fehlersuche extrem spannend, wenn man nicht weiß warum die Funktion nichts machte.



Exceptions sind schon was Tolles, das auch gute Infos geben könnte.

[jfheins]

Zitat von himitsu:

aber erstmal wird oft genug vergessen das Result von Funktionen auszuwerten
und dann macht es die Fehlerbehandung und auch Fehlersuche extrem spannend, wenn man nicht weiß warum die Funktion nichts machte.

Da gefällt mir übrigens sehr der Ansatz von Rust (ohne, dass ich das bisher selbst probiert habe): Die Funktion gibt einen Result-Typen zurück, und man muss prüfen ob es ein SuccessResult ist, bevor man an den Wert dran kommt. (https://doc.rust-lang.org/stable/rus...or/result.html)
Bzw. Im Regelfall nimmt man das Result einer Funktion und hängt einfach eine Operation an den Erfolg an. Allso ein automatisches

Delphi-Quellcode:

res := strtoint(text)
if res.Success then
  Result := TResult.Create(Success, res.Value * 2)
else
  Result := res

Dürfte in Delphi aber kniffelig umzusetzen sein, weil es als varianter record immer den Zugriff auf den Erfolg zulässt und/oder (als Klassenhierarchie) den Aufrufer mit der Speicherfreigabe "beglückt".

[Benmik]

Zitat von bernau:

Warum nur mit Boolean als Result?

Es ist vielleicht nur ein vorübergehender Zustand und auch der EXIFerei geschuldet, aber ich habe angefangen, praktisch alle Prozeduren in boolesche Funktionen umzuwandeln, bei denen der Wert per var übergeben wird.
Erstens kann man dadurch mehr als einen Wert übergeben, und zweitens finde ich den Aufruf

Delphi-Quellcode:

If BestimmeHeaderPos(HeaderPos) then begin
  MachWasMitHeaderPos;

viel praktischer als

Delphi-Quellcode:

HeaderPos := BestimmeHeaderPos;
If HeaderPos > 0 then begin
  MachWasMitHeaderPos;

[himitsu]

Zitat von jfheins:

Die Funktion gibt einen Result-Typen zurück, und man muss prüfen

Ich war mir sicher, dass es im Delphi/Pascal auch einen Compilerschalter gab, wo der Compiler einen Fehler oder eine Warnung warf, wenn das Result einer Funktion nicht ausgewertet wird. (nicht in einem IF, an eine Variable zugewiesen oder als Parameter genutzt)

Aber ich find grade nicht.

[Uwe Raabe]

Zitat von himitsu:

Ich war mir sicher, dass es im Delphi/Pascal auch einen Compilerschalter gab, wo der Compiler einen Fehler oder eine Warnung warf, wenn das Result einer Funktion nicht ausgewertet wird.

Das ist Teil des Compiler-Schalters $X (Erweiterte Syntax):

Zitat:

Dient nur der Abwärtskompatibilität. Verwenden Sie diese Option (entspricht {$X-}) nicht in Ihren Delphi-Anwendungen. Mit dieser Option wird die erweiterte Syntax von Delphi aktiviert oder deaktiviert:

Funktionsanweisungen. Im Modus {$X+} können Funktionsaufrufe als Prozedurenaufrufe verwendet werden, d. h. das Ergebnis eines Funktionsaufrufs kann ignoriert werden, anstatt an eine andere Funktion übergeben oder in einer Operation bzw. Zuweisung verwendet zu werden. Im Allgemeinen werden die von einer Funktion ausgeführten Berechnungen durch das Funktionsergebnis repräsentiert, das nicht ignoriert werden sollte. Manchmal führen Funktionen aber lediglich eine bestimmte Operation durch (z. B. einer globalen Variablen einen Wert zuweisen) und geben keinen Wert zurück, der weiterverwendet werden kann.

Result-Variable. Wenn die Option aktiviert ist (entspricht {$X+}), kann die vordefinierte Result-Variable für den Rückgabewert der Funktion verwendet werden.

Nullterminierte Strings. Wenn diese Option aktiviert ist, können Delphi-Strings nullbasierten Zeichen-Arrays (array[0..X] of Char) zugewiesen werden, die mit PChar-Typen kompatibel sind.

Leider ist bei $X- auch die Verwendung von Result anstatt des Funktionsnamen für den Rückgabewert nicht mehr möglich. Das wird aber aktuell soviel verwendet, dass vermutlich kaum ein Programm noch mit $X- compileren würde.

[Stevie]

Zitat von jfheins:

Da gefällt mir übrigens sehr der Ansatz von Rust (ohne, dass ich das bisher selbst probiert habe): Die Funktion gibt einen Result-Typen zurück, und man muss prüfen ob es ein SuccessResult ist, bevor man an den Wert dran kommt.

Puh, das driftet jetzt aber sehr ab - Result<T,E> in Rust ist aus der funktionalen Programmierung, um die Abwesenheit eines Wertes (in anderen Sprachen oft mit einem Nullable<T> modelliert), oder einen Fehler ohne Exception raising darzustellen, womit man sehr gut pure Funktionen aneinanderketten kann. Siehe auch die Präsentation "Railway Oriented Programming" von Scott Wlaschin.

Ich hab über diese Thematik übrigens auch schon gebloggt:
https://delphisorcery.blogspot.com/2...nil-maybe.html
https://delphisorcery.blogspot.com/2...or-delphi.html

Kommt jetzt aber arg vom Thema "Exit oder nicht" ab