Verständnisfrage zu Exit

[himitsu]

"Logisch" sind ELSE eigentlich passend,
auch wenn beim EXIT das ELSE unnötig wäre.

Wenn man aber mit ELSE und nur Result:= arbeitet, dann hat man z.B. die Chance ans Ende "einen" Haltepunkt zu setzen oder eine Loggingfunktion dort einzufügen, was bei den Exits (zentral) nicht ginge.


Was ich heute in der Hilfe vom VBScript sah .... im Delphi braucht man zum Glück nicht mehr Funktionsname := ...; und kann fehlerunanfäliger mit Result arbeiten. (sogar lesend)

[Uwe Raabe]

Zitat von himitsu:

Wenn man aber mit ELSE und nur Result:= arbeitet, dann hat man z.B. die Chance ans Ende "einen" Haltepunkt zu setzen oder eine Loggingfunktion dort einzufügen, was bei den Exits (zentral) nicht ginge.

Das Exit springt aber doch an das end der Function. Dort kannst du doch den Haltepunkt setzen.

[himitsu]

Nicht immer.
Keine lokalen Variablen und Dergleichen und schon kann Exit auch direkt rausspringen.

[mkinzler]

Wenn die Bedingung wahr ist wird das else eh nicht abgearbeitet.

[stahli]

Da gibt es unterschiedliche Auffassungen, die aber eher dem persönlichen Geschmack geschuldet sind.

Der Code sieht halt mit und ohne Exit unterschiedlich aus.
Funktionelle Probleme bzw. Fehler gibt es durch Exit jedoch nicht.

Du kannst mit Exit in einer Funktion auch direkt den Rückgabewert mitgeben.

Delphi-Quellcode:

if A then 
begin
  Exit(1);
end
else 
if B then...

Zu beachten ist, dass bei Exit in einem try-finally-Block in den finally-Abschnitt gesprungen wird (und danach - glaube ich - direkt aus der Methode).

[dummzeuch]

Zitat von stahli:

Du kannst mit Exit in einer Funktion auch direkt den Rückgabewert mitgeben.

Delphi-Quellcode:

if A then 
begin
  Exit(1);
end
else 
if B then...

Aber mit Delphi 6, das er laut Profil einsetzt. Das kam erst in einer der XE-Versionen.

[Delphi-Laie]

Zitat von kagi3624:

Als C/C++ Vorgeschädigter denke und schreibe ich immer noch ein result hin und erwarte das ende der Funktion. Nun, da Delphi ja bei einem result nicht die Funktion beendet, dachte ich exit zu benutzen, davor wird in der Delphi Basics Hilfe aber gewarnt. Was spricht eigentlich dagegen sowas zu schreiben und sich anzugewöhnen

Delphi-Quellcode:

if A then begin
  result := 1;
  exit;
end
else if B then...

Die ganzen nachkommenden else if Abfragen brauch ich ja nicht durchzugehen, wenn ich meine Funktion hier beenden will?

Dagegen spricht nichts.

Ich verstehe die Frage bzw. das Problem nicht.

In C und seinen Derivaten werden mit return der Rückgabewert festgelegt und die Funktion verlassen. In Pasal, Delphi und seinen Derivaten gibt es dafür zwei getrennte Befehle. Der Funktionswert kann innerhalb der Funktion sogar beliebig oft geändert werden. Er sollte aber bei jedem Funktionsdurchlauf wenigstens einmal einen Wert zugewiesen bekommen, ansonsten ist der Rückgabewert unbestimmt.

[Benmik]

Auch wenn das Thema so ziemlich abgehandelt ist, interessiert mich doch noch ein Aspekt.

Ich arbeite im Moment an einer EXIF-Unit. Die Exiferei ist ein Gebiet, auf dem man alles, wirklich alles pausenlos abprüfen muss, weil dort das reine Faustrecht herrscht (ja, Microsoft und Adobe, ihr seid gemeint!). Dementsprechend ist ein Result ausschließlich am Ende völlig illusorisch, weil es nur noch boolesche Funktionen gibt und die voll sind von Results.

Dementsprechend wäre für die Funktionen Folgendes sinnvoll:

Delphi-Quellcode:

Result := KlapptDas1;
Result := Result and KlapptDas2;
Result := Result and KlapptDas3;
Result := Result and KlapptDas4;
If Result then begin
 ... // jetzt kann es losgehen

Vor allem auch für das Debuggen ist das enorm praktisch, weil man sich durchF8en kann und sofort sieht, wenn Result False wird. Und sehr übersichtlich ist es auch, was ja für Code nicht das Schlechteste ist. Andererseits sieht man sowas im Proficode nie, woraus ich schließe, dass es aus mir unerfindlichen Gründen verpönt ist (Himitsu, lass das "h" weg, das kommt von poena!). Mein Gedanke ist nun: Der Compiler lässt das alles doch sowieso nicht so, wie wir das hinschreiben. Es kann doch oft sein, dass die "offziellen" Elaborate überhaupt kein anderes Ergebnis erbringen als der Code oben, und schon mal überhaupt keinen Geschwindigkeitsunterschied. Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

[dummzeuch]

Zitat von Benmik:

Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

Um mal Knuth zu ziteren:

Zitat:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

Solange es also kein Performance-Problem gibt, sollte man nicht optimieren. Wenn es eines gibt, sollte man erst durch Timing herausfinden, wo man am meisten erreichen kann.

Angewandt auf Dein Beispiel: Debugging-freundlicher Code ist guter Code, es sei denn, er ist nachweisbar ein Performance-Problem.

[Benmik]

Zitat von dummzeuch:

Um mal Knuth zu ziteren:

Das Zitat von Knuth kannte ich und ich finde, dass sollte man mal in goldenen Lettern irgendwo anschlagen.

Zitat von bernau:

Breakpoint auf alle Exit und du springst sofort auf den betreffenden Exit ohne mit F8 durch zappen zu müssen.

Das ist ja schlau.
Vor Kurzem hat Himitsu sein

Delphi-Quellcode:

If Bedingung = Erfüllt then
  Sleep(0)

gepostet und da habe ich mich gefragt, warum ich nicht selbst darauf gekommen bin.

Ansonsten - OK, da bin ich ja beruhigt.