Anfängerfrage IF - THEN - ELSE

[phXql]

if-Anweisungen sind return (das selbe wie Exit) vorzuziehen, zumindest meinte das unser Prof in Java. Grund: man kann den Breakpoint auf das Ende der Methode setzen (da wo das return steht) und sieht immer, was zurückgegeben wird. Wenn mittendrin irgendwo rausgesprungen wird, geht das nicht mehr.

Raise nicht zu benutzen is blödsinn, wie soll man denn sonst Exceptions werfen?

[taaktaak]

Moin, Moin,
sehe ich auch so wie meine Vorredner: GOTO ist fast immer vermeidbar, aber warum sollte ich die anderen Sprachelemente nicht nutzen? Wenn ich z.B. in einer unsortierten Liste nach einem Element suche, dann kann ich die Schleife - so das Element gefunden ist - doch sinnigerweise abbrechen: Mit BREAK funktioniert das ideal. BREAK verwende ich daher häufig - ohne dabei ein schlechtes Gewissen zu haben :lol:

[grenzgaenger]

stimmt, die gogo's goto, break, continue, halt, exit, return, raise exception sind in aller regel vermeidbar. was nicht heisst, dass sie nicht bequem sind... :-) . was aber nicht heisst, dass sie der strukturierten programmierung entsprechen. ganz im gegenteil, da sind diese verboten :warn: .

besonders anfänger sollten sich aber an zwei sachen gewöhnen

• ordentliche code einrückungen
• strukturierte programmierung

denn wenn diese beiden punkte berücksichtigt sind, gibts (a) viel weniger fehler und (b) sind die verbleibenden fehler einfacher zu finden. :warn:

selbst halte ich das raise exception für ziemlich problematisch (problematischer als die grundform goto), sehe aber auch, dass diese anweisung für die objektübergreifende fehlerkommunikation sinnvoll eingesetzt werden kann. ansonsten würde ich hierauf möglichtst verzichten.

Zitat:

Zitat von Nuclear-Ping

Zitat:

Zitat von wicht

... ich glaube, dass das nur Probleme bringt, wenn man nicht weiß, wie man das zu benutzen hat...

Denke ich nämlich auch.

in diesem fall kann man alles benützen, wenn man sich damit auskennt. teilweise sind ja dann auch die seiteneffekte gewünscht :-)

PS: ich selbst hatte früher auch extensiv mit den oben genannten controllstrukturen gearbeitet, bis der compiler durcheinander kam und das progy nur noch wilde dinge tat. hier kam er wohl mit den rücksprungadressen 'n wenig durcheinander... von daher auch meine programmtechnische warnung, diese nur mit bedacht einzusetzen.

[omata]

@grenzgaenger: Ich danke dir für deine Kommentare, ich sehe das genauso.
Wenigstens einer, der sinnvolle Regeln einhält und den Sinn verstanden hat.

@Nuclear-Ping: Du favorisierst damit eine negative Logik.
Ich persönlich denke gern positiv und ziehe deshalb genau die andere Lösung vor.

[Die Muhkuh]

Hi,

könnten die Vorredner mal ein Beispiel zeigen, wie man ein Break bzw. ein raise ersetzt?

[omata]

Ein break optimiert man mit einer boolschen Variable weg.
Und ein raise ist eine der erwähnten Ausnahmen. Die Fehlerbehandlung gehört nunmal nicht zur strukturierten Programmierung und ist deshalb die einzige Möglichkeit. Da es also keine Alternative gibt, ist raise ok.

[xZise]

Zitat:

Zitat von Die Muhkuh

[...]könnten die Vorredner mal ein Beispiel zeigen, wie man ein Break bzw. ein raise ersetzt?

Bin zwar kei Vorredner ^^ aber zumindest "break" kann man mit while und/oder mit einem Boolean umgehen.

Delphi-Quellcode:

for i := 0 to 1234 do
  if i = 987 then
    break;

Nicht gerade so viel besser in der Perfomance:

Delphi-Quellcode:

Breaked := false;
for i := 0 to 1234 do
  if not Breaked then
  begin
    if i = 987 then
      Breaked := true;
  end;

Das sollte am schnellsten von allen sein:

Delphi-Quellcode:

i := 0;
Breaked := false;
while (i <= 1234) and (not Breaked) then
begin
  if i = 987 then
    Breaked := true;
end;

Wem i nur in der Schleife wichtig ist:

Delphi-Quellcode:

i := 0;
while (i <= 1234) then
begin
  if i = 987 then
    i := 1235;
end;

Und "raise" könnte man nur durch rückgabeparameter ablösen:

Delphi-Quellcode:

function Something : Integer;
begin
  Result := 0;
  <Mach das und das>
  if <Irgendwas falsch> then
    Result := 1;
end;

MfG
xZise

[phXql]

Nein, raise ersetzt man auf KEINEN fall mit rückgabeparametern.

Exceptions kann man nicht ignorieren, Rückgabewerte schon.

// Edit: hähähä, Exceptions ignorieren kann man schon, aber dann kann man demjenigen Vorsatz vorwerfen:

Code:

try
{
 foobar();
}
catch(Exception)
{
}

[taaktaak]

Moin, Moin.

Ein Beispiel? Für BREAK, hier ist es...

Delphi-Quellcode:

function GetInternetAddr(MenuItem:String):String;
 var i : Integer;
 begin
   Result:='';
   for i:=0 to pred(MSDNList.Count) do
     if pos(MenuItem,MSDNList[i])>0 then begin
       Result:=MSDNList[i];
       Break;           
       end;
 end;

MSDNList ist eine StringListe die Strings im Format MenuItem+'|'+WebAddress enthält, die Liste ist (und bleibt) klein (<100 Einträge), eine Element wird daraus gesucht. Natürlich kann man in einer sortierten Liste anders suchen, na klar!. Der Geschwindigkeitsunterschied bei einer so geringen Anzahl von Elementen ist m.E. akademisch! Aber gehen wir mal davon aus, dass wir mit einer unsortierten Liste arbeiten müssen! Insgesamt halte ich obige Funktion für effizient, übersichtlich und angemessen - oder ?????

[omata]

Hier mal die strukturierte Variante...

Delphi-Quellcode:

function GetInternetAddr(MenuItem:String):String;
var i : Integer;
    abbruch:boolean;
begin
  Result:='';
  i:=0;
  abbruch:=false;
  while (i < MSDNList.Count) and not abbruch do begin
    if pos(MenuItem, MSDNList[i]) > 0 then begin
      Result:=MSDNList[i];
      abbruch:=true;
    end;
    inc(i);
  end;
end;

Edit: Eine For-Schleife benutzt man nie, wenn man die Schleife vorzeitig abbrechen möchte/muss.