Anfängerfrage IF - THEN - ELSE

[Geist]

Hallo zusammen,

ich möchte eine procedure bei bestimmten Bedingungen beenden. Wie geht das?


procedure TForm1.Taste2Click(Sender: TObject);
begin
if Form1.ADOConnection1.Connected = false then
messageDlg('Noch nicht mit der Datenbank verbunden.',mtError,[mbOK],0);
------------hier soll dann Schluss sein --------------

oder hier soll es bei ...=true weiter gehen...........

end;

Danke schon mal
Heiko

[Der.Kaktus]

hi,

Delphi-Quellcode:

procedure TForm1.Taste2Click(Sender: TObject); 
begin 
if not Form1.ADOConnection1.Connected  then 
begin
 messageDlg('Noch nicht mit der Datenbank verbunden.',mtError,[mbOK],0);
 exit;
end else (*Deine Befehle*) ;

[Luckie]

Zitat:

Zitat von Geist

ich möchte eine procedure bei bestimmten Bedingungen beenden. Wie geht das?

Im Titel hast du doch schon die richtigen Schlüsselwörter aufgezählt. ;? Übersetze sie doch einfach mal ins Deutsche: wenn, dann, ansonsten. Und dann kann man noch in der Delphi Hilfe oder in Einsteiger-Tutorials gucken.

[Geist]

wie das mit dem IF THEN ELSE funktioniert ist mir schon so einigermaßen klar.

Ich möchte aber die Procedure aber beenden wenn bestimmte Bedingungen nicht erfüllt sind.
Sprich, es soll gleich zu END 'gesprungen' werden.

[mkinzler]

Delphi-Quellcode:

Exit;

[DeddyH]

Das Exit ist IMHO nicht unbedingt nötig.

Delphi-Quellcode:

procedure TForm1.Taste2Click(Sender: TObject);
begin
  if not Form1.ADOConnection1.Connected  then
    begin
      MessageDlg('Noch nicht mit der Datenbank verbunden.',mtError,[mbOK],0);
    end 
  else 
    begin
      (* Mit der DB arbeiten *)
    end;
end;

[Tommy1988]

Am besten niemals aus True oder False fragen ;)

Delphi-Quellcode:

if not Form1.ADOConnection1.Connected  then

so ist es besser..

Delphi-Quellcode:

if not WAHR then // ...
if WAHR then // ...

[DeddyH]

Was willst Du mir damit sagen? Ich benutze doch not :gruebel:

[Die Muhkuh]

Er bezieht sich auf den original Source, Detlef.

[DeddyH]

Zitat:

Zitat von Die Muhkuh

Er bezieht sich auf den original Source, Detlef.

Zitiert mich aber dabei.

[Die Muhkuh]

Weil Deine Fassung die bessere ist. Steht doch drunter: "So ists besser".

Der Rest des Sources ist nur noch mal Verdeutlichung.

[grenzgaenger]

Zitat:

Zitat von DeddyH

Das Exit ist IMHO nicht unbedingt nötig.

Delphi-Quellcode:

procedure TForm1.Taste2Click(Sender: TObject);
begin
  if not Form1.ADOConnection1.Connected  then
    MessageDlg('Noch nicht mit der Datenbank verbunden.',mtError,[mbOK],0)
  else 
  begin
    ; //hier kommt dein code 
      (* Mit der DB arbeiten *)
  end;
end;

mach es so wie DeddyH es empfohlen hat. alles andere entspricht nicht der strukturierten programmierung.

Vote4DeddyH :-)

[DeddyH]

[OT]

Zitat:

Zitat von grenzgaenger

Vote4DeddyH :)

Thx :lol: [/OT]

[Der.Kaktus]

[OT]
mal Wischlappen und Eimer zum grenzgaenger stellt...*schleimspurentfernen* *fg* :bounce2:[/OT]

[Geist]

ja, das war es.
EXIT
ist das Zauberwort, danach habe ich gesucht.
vielen Dank noch mal

[grenzgaenger]

ihr wisst schon, dass man die goto anweisungen (goto, break, continue, exit, raise exception) nur in ganz wenigen ausnahmefällen verwenden darf, da man sich sonst sehr viel mehr ärger einhandelt. :warn:

[Nuclear-Ping]

Nämlich?

[Thorben_Ko]

[OT]Klar man bekommt ärger mit dem grenzgaenger wenn er das liesst -.-

Sry konnte ich mir net verkneifen[/OT]

[wicht]

Gut, goto benutze ich auch nicht, aber break, continue, exit und raise Exception benutze ich schon des öfteren, und ich glaube, dass das nur Probleme bringt, wenn man nicht weiß, wie man das zu benutzen hat... von daher sollte man das vielleicht nicht so stehen lassen.

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

Ich persönlich favorisiere ...

Delphi-Quellcode:

procedure TForm1.ButtonDeleteClick(Sender: TObject);
begin
  if not MessageDlg ('Sicher?', mtConfirmation, [mbYes, mbNo], 0) = IDNO then
    Exit;
  
  DeleteFiles;
  RefreshView;  
end;

... vor ...

Delphi-Quellcode:

procedure TForm1.ButtonDeleteClick(Sender: TObject);
begin
  if MessageDlg ('Sicher?', mtConfirmation, [mbYes, mbNo], 0) = IDYES then
    begin  
      DeleteFiles;
      RefreshView;  
    end;
end;

... Macht zwar das gleiche, aber meine Leertaste wirds mir danken. ;)

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

[taaktaak]

Hallo omata,
ich sehe in deiner Variante, die selbstverständlich funktioniert, keinen Vorteil; ich halte sie sogar für ineffizient: Sie benötigt mehr Tipparbeit, ist (für mich) unübersichtlicher und mit Sicherheit nicht schneller. Warum sollte ich dieses Konstrukt einsetzen? Nur um das Break zu vermeiden?

[omata]

Das musst du natürlich für dich entscheiden.

Ich hatte noch nie Probleme mit dem Tippen.
Wie auch immer ich versuche eben strukturiert zu programmieren. Das muss man ja nicht, wenn dir das egal oder nicht wichtig ist ist das nunmal so. Trotzdem finde ich es eben sinnvoll einem Anfänger nicht gleich die "bösen" Befehle beizubringen, nur weil man selber zu "faul" ist. Ok, wenn man es nicht besser weiss ist das nunmal so, deshalb ergibt so sein Thread immer gleich so eine riesige Grundsatzdiskussion.
Wenn die Anwendungen großer werden, ist es nunmal sinnvoll struktiriert zu arbeiten.
Ich persönlich weiss meist nicht gleich das die Anwendung, die ich beginne riesig wird. Deshalb designe ich das gleich ordentlich, weil ich mich eben kenne. Das wird nachträglich nicht mehr angepasst, nach dem Motto läuft doch. Wenn es dann aber irgendwann an irgendeiner Stelle Probleme gibt dann viel Spass bei der Fehlersuche.

Deshalb finde ich solche Threads dann irgendwann nur noch bedauerlich, wenn es nur noch darum geht für die unstrukturierten Befehle eine Daseinsberechtigung zu finden.

Deshalb die einfache Frage warum nicht gleich ordentlich und strukturiert arbeiten?
Nur weil es angeblich Tipparbeit bedeutet?

[phXql]

Faulheit ist bekanntlich die Mutter aller Erfindungen :)

PS: Das heißt nich, dass ich Spaghetti-Code befürworte..

[grenzgaenger]

Zitat:

Zitat von phXql

Faulheit ist bekanntlich die Mutter aller Erfindungen :)

PS: Das heißt nich, dass ich Spaghetti-Code befürworte..

:wink: dafür kommt der spass beim debuggen und beim überarbeiten 8)

und mal ehrlich, wieviele threads hier gehen auf kosten von schlechten einrückungen und daraus resultierenden fehlern? 10%, 20%?

[xZise]

Zitat:

Zitat von 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)
{
}

Erstens habe ich extra ein "nur" darein getippt, und zweitens gibt es soweit ich weiß, Funktionen die einen Rückgabeparemter mit dem Fehler haben.
Bevor du fragst: Ich kann dir nicht die Funktionsnamen nennen, aber ich glaube das sind API-Funktionen.

MfG
xZise

[taaktaak]

Omata, ich gebe dir prinzipiell Recht - keine Frage! Insbesondere, dass viele Sources fast immer länger und umfangreicher werden, als ursprünglich eingeschätzt.

Was an meinem Beispiel aber so unstrukturiert ist, das erschließt sich mir beim besten Willen nicht.

// OT - Das können wir bei einem Milchkaffee im "Venezia" besprechen!

[phXql]

Zitat:

Zitat von xZise

Erstens habe ich extra ein "nur" darein getippt, und zweitens gibt es soweit ich weiß, Funktionen die einen Rückgabeparemter mit dem Fehler haben.
Bevor du fragst: Ich kann dir nicht die Funktionsnamen nennen, aber ich glaube das sind API-Funktionen.

Jo, mit den Funktionen hast du wohl recht. Fast alle WinAPI calls benutzen return values. Da hat MS dazugelernt und rät vom Gebrauch von return values in .NET z. B. ab. Und das is auch gut so. Exceptions kosten zwar einiges mehr (nicht Euro, sondern Taktzyklen), dafür erhöhen sie die Qualität der Software ungemein.