Autor Beitrag
Hidden
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 13:02 
Hi,

Bisher habe ich in verschieden Themen gelesen, dass die o.ä. GoTo ruhig mal zu Beginn von Prozeduren bei Abbruchbedingungen(Exit), bzw. bei Suchschleifen(for) nach Fund, verwendet werden dürfen. Selbstverständlich gut kommentiert.

Mein Lehrer meinte jetzt aber letztens, jedes GoTo stelle eine Sicherheitslücke im Programm dar :shock: und die o.ä. seien GoTo zum Ende der Prozedur/Schleife.

Wie seht ihr das, was habt ihr da gelernt und was ist dran?

mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
Yogu
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2598
Erhaltene Danke: 156

Ubuntu 13.04, Win 7
C# (VS 2013)
BeitragVerfasst: Sa 05.04.08 13:08 
Hallo,

wenn du mal das CPU-Fenster von Delphi anschaust und per F8 die Befehle durchgehst, wirst du schnell eins bemerken: Der Code steckt voller Sprünge. Andauernd ladet man wo anders - das können nur Gotos sein. Wenn das eine Sicherheitslücke ist, dann wäre Delphi eine komplett unsichere Sprache.

Und wenn du mal selber etwas Assembler angeschaut hast, dann siehst du auch, dass es gar nicht ohne Sprünge geht. Es gibt eigentlich keine Möglichkeit, ohne Sprünge zu arbeiten. Delphi macht das ganze für dich, du bekommst da gar nichts mit. Jede Funktion oder Prozedur, jede IF-Verschachtelung und jede CASE-Anweisung, wie soll das denn anders gehen? Da stecken überall Sprünge dahinter.

Vielleicht meint dein Lehrer, dass unter Umständen Variablen nicht gesetzt sein können, oder sonst irgendwas falsch gemacht werden kann. Aber solche Situationen kommen andauernd - man muss halt aufpassen und genug Fehlerbehandlungen einbauen.

(Anmerkung: Ich hab kein Informatik, daher auch keinen Leher in der Richtung)

Grüße,
Yogu
Hidden Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 13:29 
Hi,

Ersteinmal danke für die schnelle Antwort!
Gut, und kann man die zwei o.e. Lösungen als sauber bezeichnen oder ist break/exit generell unsauber?

Edit:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
procedure dosomething;
begin
  if not myBoolean then Exit;
  {langer Prozedurequelltext, der sonst hier ins else müsste(bzw. not else -> hauptteil)}
end;

function search(aSearchFor: Variable): Variable;
var
  i: Integer;
begin
  for k := 0 to LimitI do
    if ... then beign
      ...
      Break;
    end;
end;


Der Vorschlag meines Lehrers im letzten Teil wäre eine While-Schleife mit inc(i) und Abbruchbedingung (i > limitI) or found. [OT]ist der Unterschied zwischen for- und While nicht, dass sich for besser optimieren lässt(Prozessor-Laufvariable)? [/OT]

Wieauchimmer, lässt sich durch Break/Exit Laufzeit spaaren?

mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)


Zuletzt bearbeitet von Hidden am Sa 05.04.08 15:47, insgesamt 2-mal bearbeitet
Yogu
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2598
Erhaltene Danke: 156

Ubuntu 13.04, Win 7
C# (VS 2013)
BeitragVerfasst: Sa 05.04.08 13:41 
user profile iconHidden hat folgendes geschrieben:
kann man die zwi o.ä. Lösungen als sauber bezeichnen oder ist break/exit generell unsauber?

Das weikß ich jetzt nicht mehr. Aber manchmal ist es doch unumgänglich: Bei einer for, wenn plötzlich auf "Abbrechen" geklickt wurde. Wie soll man da ohne Break oder Exit wieder rauskommen?
BenBE
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: Sa 05.04.08 13:43 
o.ä. = oder ähnliches ??? Oder meinst Du o.e. (oben erwähnte)???

Break und Exit sind oftmals nützlich, können aber in Einzelfällen dazu führen, dass das Programm dadurch unübersichtlicher wird, gerade dadurch, dass der normale Programmfluss geändert wird. Ein Sicherheitsrisiko per se sind diese beiden Befehle nicht; nur, wenn sie in die Hände schlampiger Programmierer geraten ...

_________________
Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
Hidden Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 13:49 
user profile iconBenBE hat folgendes geschrieben:
o.ä. = oder ähnliches ??? Oder meinst Du o.e. (oben erwähnte)???

:oops: Ja
user profile iconBenBE hat folgendes geschrieben:
Break und Exit sind oftmals nützlich, können aber in Einzelfällen dazu führen, dass das Programm dadurch unübersichtlicher wird

Jo, wie gesagt:
user profile iconHidden hat folgendes geschrieben:
Selbstverständlich gut kommentiert.

mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)


Zuletzt bearbeitet von Hidden am Sa 05.04.08 15:48, insgesamt 1-mal bearbeitet
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Sa 05.04.08 14:29 
user profile iconBenBE hat folgendes geschrieben:
diese beiden Befehle nicht; nur, wenn sie in die Hände schlampiger Programmierer geraten ...

In Händen von schlampigen Programmierern ist alles eine Sicherheitslücke. ;)
Grenzgaenger
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Sa 05.04.08 16:31 
user profile iconHidden hat folgendes geschrieben:
Hi,

Ersteinmal danke für die schnelle Antwort!
Gut, und kann man die zwei o.e. Lösungen als sauber bezeichnen oder ist break/exit generell unsauber?

Edit:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
procedure dosomething;
begin
  if not myBoolean then Exit;
  {langer Prozedurequelltext, der sonst hier ins else müsste(bzw. not else -> hauptteil)}
end;

function search(aSearchFor: Variable): Variable;
var
  i: Integer;
begin
  for k := 0 to LimitI do
    if ... then beign
      ...
      Break;
    end;
end;


ja, das ist eine unsaubere programmierung. in der strukturierten programmierung wirst du codekonstrukte al'la goto, break, exit auch gar nicht finden. dort sind die routinen so aufzubauen, dass sie sauber den jeweiligen codeblock verlassen.

im übrigen, gibts ja nur zwei möglichkeiten zu springen, bedingt und unbedingt. von den schleifen gibts auch nur zwei typen, die kopf- und die fussgesteuerten. vom compiler werden sie mit bedingten oder unbedingten sprunganweisungen umgesetzt. dies heisst jedoch nicht, dass das auf der quellcodeebene auch sein sollte. ganz im gegenteil. damit der compiler sauber arbeiten kann, braucht er ordentliche strukturen, und da kommt er teilweise mit den oben genannten controllkonstruktren durcheinander. daher mein tipp, möglichst vermeiden und wenn dann nur gewählt einsetzen... sonst kommen leicht nächtelange debuggingsessions auf dich zu, wo die fehler nur schwer zu lokalisieren sind.

PS: ebenfalls ist die EXCEPTION ein tötliches konstrukt, welches nur in absoluten ausnahmen eingesetzt werden sollte. mit der strukturierten programmierung hat dies gar nix zu tun.

<HTH> GG

PS: weshalb nicht so umsetzen:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
procedure dosomething;
begin
  if myBoolean then 
  begin
    {langer Prozedurequelltext, der sonst hier ins else müsste(bzw. not else -> hauptteil)}
  end;
end;

function search(aSearchFor: Variable): Variable;
var
  i: Integer;
begin
 k := 0;
 while (k <= limitI) and ... do
 begin

  inc(k);
 end;


Der Compiler macht ja nix anderes draus...
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Sa 05.04.08 16:44 
user profile iconGrenzgaenger hat folgendes geschrieben:
PS: ebenfalls ist die EXCEPTION ein tötliches konstrukt, welches nur in absoluten ausnahmen eingesetzt werden sollte. mit der strukturierten programmierung hat dies gar nix zu tun.

Kannst du das Begründen und mit Beispielen untermauern? Ich sehe das nämlich etwas anders. Und wenn es tödlich wäre, dann müsste es mittlerweile schon unzähliche tote Programme geben.
AHT
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 207



BeitragVerfasst: Sa 05.04.08 17:14 
user profile iconHidden hat folgendes geschrieben:


Mein Lehrer meinte jetzt aber letztens, jedes GoTo stelle eine Sicherheitslücke im Programm dar :shock: und die o.ä. seien GoTo zum Ende der Prozedur/Schleife.

Wie seht ihr das, was habt ihr da gelernt und was ist dran?



Mmh... - frage deinen Lehrer mal, wo genau da die Sicherheitslücke sein soll. Im Prinzip dürfte das, wie vieles andere auch, als OP-Code in Jump- oder Returnbefehlen enden.

Was ich gelernt habe - ist aber schon zwanzig Jahre her:
GOTOs machen den Code unübersichtlichg. Hat dein Lehrer da andere Infos, würde mich das sehr interessieren. Lehrer sind doch dafür da, einem etwas zu erklären - und zwar so, dass man das auch versteht. Löchere den doch mal ein bischen...
Hidden Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 17:41 
Hi,

angenommen, ich habe einen Code folgender Form:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
procedure doSomeThing(X, Y, Z: Integer);
begin
  try
    if myArray[X, Y, Z] then Exit;  //der Einfachheit halber ein Array of Boolean
  except //unzulässige Indizes ignorieren
  end;
  //eigentlicher Prozedurtext
end;



[OT]
Eigentlich geht es um ein Schachprogramm. Um herauszufinden, ob ein König im Schach steht, gehe ich alle Richtungen vom König aus in for-Schleifen durch und checke beim Finden einer Figur, ob es sich um eine Figur handelt, die aus dieser Richtung Schach geben kann. Wenn ja, kommt ein Exit(vorher habe ich result auf false(kein Schach) gesetzt). Ansonsten kommt ein Break, da aus dieser Richtung keine andere Figur mehr Schach geben kann.

Die Springer muss ich seperat betrachten, da sie nicht aus einer der acht Richtungen vom König aus Schach geben. nun checke ich einfach, ob auf den Feldern mit den Positionen (+2/+1)usw... feindliche Springer stehen. Diese Indizes können außerhalb des Feldes(2D-Array) liegen.

Nun wären für mich drei Lösungen möglich: a)Feld größer machen und außen mit nil füllen. b) Indizes einzeln auf Validität prüfen c) try und bei Except ignorieren.

Sry für ein so langes OT, sollte es zu dem Beispiel fragen geben, bitte über PM nachdenken.
[/OT]

mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Sa 05.04.08 18:57 
user profile iconHidden hat folgendes geschrieben:
c) try und bei Except ignorieren.

Wozu dann einen try-except-Block, wenn du die Exception doch ignorierst? So soll man ja Exceptions auch nicht verwenden. :roll:
Silas
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 478

Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
BeitragVerfasst: Sa 05.04.08 18:57 
user profile iconGrenzgaenger hat folgendes geschrieben:
in der strukturierten programmierung wirst du codekonstrukte al'la goto, break, exit auch gar nicht finden. dort sind die routinen so aufzubauen, dass sie sauber den jeweiligen codeblock verlassen.

Wenn du beispielsweise ein Array durchsuchst, kommst du um ein Break gar nicht herum (es sei denn, du NOPst dich durch die restlichen Durchläufe).

user profile iconGrenzgaenger hat folgendes geschrieben:
PS: ebenfalls ist die EXCEPTION ein tötliches konstrukt, welches nur in absoluten ausnahmen eingesetzt werden sollte. mit der strukturierten programmierung hat dies gar nix zu tun.

Das stimmt auf jeden Fall nicht. Bei einer Exception werden alle kritischen, vom Compiler vorgenommenen Aktionen rückgängig gemacht (siehe z.B. Stack-Unwinding).

Exit zu vermeiden, ist in den meisten Fällen sinvoll, wenn man allerdings ein begin-end-Konstrukt über die ganze Prozedur vermeiden kann, macht die Verwendung Sinn.

_________________
Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat ;-)
Yogu
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2598
Erhaltene Danke: 156

Ubuntu 13.04, Win 7
C# (VS 2013)
BeitragVerfasst: Sa 05.04.08 19:24 
user profile iconSilas hat folgendes geschrieben:
Wenn du beispielsweise ein Array durchsuchst, kommst du um ein Break gar nicht herum (es sei denn, du NOPst dich durch die restlichen Durchläufe).

Warum nicht so, wie user profile iconGrenzgaenger vorgeschlagen hat?

user profile iconGrenzgaenger hat folgendes geschrieben:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
function search(aSearchFor: Variable): Variable;
var
  i: Integer;
begin
 k := 0;
 while (k <= limitI) and ... do
 begin

  inc(k);
 end;
Silas
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 478

Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
BeitragVerfasst: Sa 05.04.08 19:43 
user profile iconYogu hat folgendes geschrieben:
Warum nicht so, wie user profile iconGrenzgaenger vorgeschlagen hat?

Stimmt, das wäre eine Möglichkeit, allerdings denke ich das das spätestens dann unübersichtlich wird, wenn man für die Bedingung zusätzliche Variablen einführen muss. Und ein Break am Ende eines if-Blocks ist IMHO wirklich sauber.

_________________
Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat ;-)
alzaimar
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2889
Erhaltene Danke: 13

W2000, XP
D6E, BDS2006A, DevExpress
BeitragVerfasst: Sa 05.04.08 22:05 
Sauber ist das, was verständlich ist.

user profile iconHidden hat folgendes geschrieben:
Der Vorschlag meines Lehrers im letzten Teil wäre eine While-Schleife mit inc(i) und Abbruchbedingung (i > limitI) or found

Und was ist bei vielen verschachtelten Schleifen? Soll man das 'found' dann mitschleppen? Hier zwei Fragmente.
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
i := 0;
  While (i<10and not found Do Begin
  k := 0;
  while (k<100and not found Do Begin
    j := 0;
    while (j<50and not found Do Begin
      ...
      if StopTheLoops (i,j,k) Then found := True;
    End
  End
End

oder
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
For i:=0 to 9 do
  For k:=0 to 99 do
    For j := 0 to 49 do begin
      ...
      if StopTheLoops (i,j,k) Then Goto DoneLoop;
    End;

DoneLoop: 
 ...

Was ist denn nun 'sauber' im Sinne von 'Klar, Verständlich und Einfach'?
Eine Prämisse der Programmierung ist doch, unnötige Konstrukte zu vermeiden und den Code so klar, einfach und verständlich wie möglich zu gestalten. Das sollte der Lehrer gegen das Dogma "Alle Gotos, Breaks und Exits sind verböten" abwägen.
user profile iconGrenzgaenger hat folgendes geschrieben:
in der strukturierten programmierung wirst du codekonstrukte al'la goto, break, exit auch gar nicht finden. dort sind die routinen so aufzubauen, dass sie sauber den jeweiligen codeblock verlassen.

Nein, das ist Quatsch, wenn es im Widerspruch zur obersten Regel (s.o.) steht.
user profile iconGrenzgaenger hat folgendes geschrieben:

PS: ebenfalls ist die EXCEPTION ein tötliches konstrukt, welches nur in absoluten ausnahmen eingesetzt werden sollte. mit der strukturierten programmierung hat dies gar nix zu tun.

Blödsinn. Wieso findet man Exceptions NUR bei modernen strukturierten objektorientierten Programmiersprachen? Ausnahmen sind genau dafür gedacht, STRUKTURIERT programmieren zu können, denn mit der modernen Exceptionbehandlung kann man endlich den normalen Ablauf kodieren, ohne nach jeder Zeile/Aufruf einen etwaigen Rückgabewert zu prüfen:
Strukturierte Programmierung à la grenzgaenger:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
ReturnCode := Step1;
If ReturnCode = RETURN_OK Then Begin
  ReturnCode := Step2;
  If ReturnCode = RETURN_OK Then Begin
    ReturnCode := Step3;
    If ReturnCode = RETURN_OK Then Begin
      ReturnCode := Step4;
      If ReturnCode = RETURN_OK Then Begin
        ReturnCode := Step5;
        ReportSuccess;
      End 
      Else 
        ShowError (ReturnCode)
     End 
     Else 
       ShowError (ReturnCode)
   End 
   Else 
     ShowError (ReturnCode)
  End 
  Else 
    ShowError (ReturnCode)
End 
Else 
 ShowError (ReturnCode);


Und so ist das laut grenzgaenger tödlich:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
Try
  Step1;
  Step2;
  Step3;
  Step4;
  Step5;
Except
  On E:Exception Do
    ShowError (E.ReturnCode)
End;

Die Frage, welches Fragment nun sicherer, wartbarer, verständlicher und robuster gegen Programmierfehler ist, erübrigt sich. Denke ich.

Abschließend würde ich deinem Lehrer erstmal folgen, denn es ist verständlich, das Breaks, Gotos und Exits am Anfang verboten sind. So lernt man erstmal, klare Programmstrukturen zu schreiben. Ihr schreibt ja schließlich nur kleine Programme, und da kann man ruhig eine Kontrolvariable (a.k.a. 'Found', 'Done' etc.) in einer Schleife mitschleppen. Bei einer einzelnen Schleife kann das durchaus Sinn ergeben, wenn nämlich dadurch der Sinn der Schleife ersichtlich wird: Eine Kontrollvariable namens 'Found' impliziert ja, das etwas gesucht wird.

_________________
Na denn, dann. Bis dann, denn.
Hidden Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 22:18 
Hi,

Der Vorschlag von Grenzgänger ist - entschuldigung :D - banal. Ich hatte erst selbst überlegt, das als Beispiel zu nehmen, es dann aber doch gelassen. Wenn ihr meinen Post lest, ist das Problem aber ein etwas anderes. Ist es aber denn(in eurem Fall) nicht schneller, eine for-Schleife zu breaken, da bei dieser dem Compiler ja klar ist, dass du z.B. ein Array durchlaufen willst? Da müsste doch ein Maximum an Optimierung drin sein. Es ist ja nicht umsonst, dass die Variable komplett Prozessorintern läuft?

user profile iconLuckie hat folgendes geschrieben:
user profile iconHidden hat folgendes geschrieben:
c) try und bei Except ignorieren.

Wozu dann einen try-except-Block, wenn du die Exception doch ignorierst? So soll man ja Exceptions auch nicht verwenden. :roll:

Bei try end; meckert er leider. wäre try finally besser? mein ziel ist, dass bei einer Zugriffsverletzung durch ungültige Indizes einfach nichts passiert(außerhalb des Bretts braucht nicht geprüft werden, ob da ein Springer steht und Schach gibt...).

(wenn der except-Teil ausgelöst wird, läuft das programm doch ohne fehlermeldung weiter, oder :? )

Edit: Mein Lehrer hat sogar gesagt, dass allgemein die Verwendung von Befehlen, die auf ein GoTo herauslaufen gleichkommt mit dem Mathe-Ansatz in meiner Signatur :wink:

ich bin ja über unterstützung froh, aber ganz so schlimm wäre es nach grenzgaenger doch nicht:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
if not(Step1 or Step2 or Step3 or Step4 or Step5) then
  ShowError (ReturnCode)

else ReportSuccess;

Die hier nötige Kommentierung würde aber den Quelltext unnötig lang machen... Nachteil wäre natürlich, dass die Rückgabewerte Boolisch sein müssten und demnach undeferenziert. Außerdem müsste man den Code in Unterprozeduren, bzw. unterfunktionen, aufteilen. IMHO sehr unsauber.

Edit2: Mein Lehrer meinte übrigens, dass das nicht seine Meinung wäre sondern die aller Info-Lehrer. Und, dass Breaks etc. ausschließlich von Schülern benutzt würden. Ich werde ihm wohl die Möglichkeit geben, sich in diesem Tread dazu zu äußern, wenn er will.

mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
Yogu
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2598
Erhaltene Danke: 156

Ubuntu 13.04, Win 7
C# (VS 2013)
BeitragVerfasst: Sa 05.04.08 22:49 
user profile iconHidden hat folgendes geschrieben:
Bei try end; meckert er leider. wäre try finally besser? mein ziel ist, dass bei einer Zugriffsverletzung durch ungültige Indizes einfach nichts passiert

Bei try ... finally wird der Finally-Teil immer ausgeführt, egal, ob eine Exception aufgetreten ist oder nicht. Das ist wohl nicht dein Ziel :)

Du brauchst wenn dann schon try ... except. Das ist aber noch nicht ganz sauber. Du solltest diese Art von "Fehlerbehandlung" (;)) nur dann einsetzen, wenn es nicht anders geht. Und wenn, dann schon so:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
try
  {Code, bei dem EMyException auftreten kann}
except
  on E: EMyException do Exit else raise;
end;

Du darfst die Exception wirklich nur verwerfen, wenn keine wirklich Ausnahme, sonder ein erwarteter Fehler aufgetreten ist. Alle anderen Fehler müssen weitergeleitet werden.

user profile iconHidden hat folgendes geschrieben:
Mein Lehrer meinte übrigens, dass das nicht seine Meinung wäre sondern die aller Info-Lehrer. Und, dass Breaks etc. ausschließlich von Schülern benutzt würden.

Da bin ich ja mal gespannt, ob ich Breaks vermeiden werde, wenn ich fortgeschrittener bin ;)
Hidden Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 2242
Erhaltene Danke: 55

Win10
VS Code, Delphi 2010 Prof.
BeitragVerfasst: Sa 05.04.08 23:06 
Hi,

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
try
  {Code, bei dem EMyException auftreten kann}
except
  on E: EMyException do Exit else raise;
end;


und, wenn ich die EAcessViolation komplett gnorieren möchte, also auch kein Exit(sry für off Topic, nur weils auch in diesem vorgeschlagen wurde)?
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
try
  {Code, bei dem EMyException auftreten kann}
except
  on not (E: EMyException) do raise;  //oder wie?
end;


mfG,

_________________
Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
alzaimar
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2889
Erhaltene Danke: 13

W2000, XP
D6E, BDS2006A, DevExpress
BeitragVerfasst: So 06.04.08 10:04 
user profile iconHidden hat folgendes geschrieben:
ich bin ja über unterstützung froh, aber ganz so schlimm wäre es nach grenzgaenger doch nicht:
ausblenden Delphi-Quelltext
1:
2:
3:
if not(Step1 or Step2 or Step3 or Step4 or Step5) then
  ShowError (ReturnCode)
else ReportSuccess;


Nee, nee das geht nicht, die Aufrufreihenfolge ist nicht gewährleistet. Was wird denn zuerst ausgeführt? 'Step1' (Auswertung von links nach rechts, oder Step5 (Auswertung von rechts nach links)? Wie optimiert das der Compiler?
Und falls Du sicherstellen kannst, das die Reihenfolge stimmt (frage mich nur, wie), ist die Abfolge vom Compilerschalter 'vollständige boolsche Auswertung' abhängig. Ist er eingeschaltet, werden nämlich alle Programmschritte ausgeführt, selbst wenn 'Step1' fehlschlägt.

Zu Deiner Exception-Frage;
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
Try
  Try
    Foobar;
  Except
    On E:EMyException Do// Nur EMyException ignorieren
    On E:Exception Do Raise;
  End
Except
 On E:Exception Do Begin
  ... // Ab hier werden Alle Exception außer EMyException behandelt.
 End
End;

Und grundsätzlich: Die Exceptionbehandlung ist so dermaßen unperformant, das es eine ganz schlechte Idee ist, damit z.B. Arraygrenzen prüfen zu lassen. Insofern ist die Ignorieren einer Exception eigentlich immer ein Anzeichen für einen falschen Ansatz.

Was in diesem Thread zum Thema Exceptions steht, ist schon bedenklich: Exceptions haben nichts mit Pickeln oder Krätze zu tun, es sind Ausnahmen zum normalen Verhalten eines Programmflusses, nicht mehr nund nicht weniger. Es ist auch kein Weltuntergang, Exceptions zu behandeln oder selbst zu generieren, sondern zeugt von fundierter Kenntnis strukturierter Programmierung. Mit Exceptions werden Programme sogar sicherer und robuster. Beispiel:
// Mit Rückgabewerten, die wir aber ignorieren:
ausblenden Delphi-Quelltext
1:
2:
RemoteConnection.Connect;
RemoteConnection.SendData; // Hier knallt es, wenn der Verbindungsaufbau nicht geklappt hat.

Wenn die Verbindung nicht geklappt hat, fahren wir das System unkontrolliert gegen die Wand. Und zwar nur deshalb, weil der Programmierer zu faul war, den Returncode auszuwerten. Oder er dachte sich: 'Klappt doch eh immer'. Wie viele Win-API-Aufrufe sind wohl so schlampig implementiert (ohne Abfrage des Returncodes), weil es schnell gehen muss?
ausblenden Delphi-Quelltext
1:
2:
  RemoteConnection.Connect;
  RemoteConnection.SendData; // Wird nicht aufgerufen da das 'Connect' eine Exception wirft.

Ich kann also als schlampiger Programmierer mit Exceptions viel weniger Mist bauen.

_________________
Na denn, dann. Bis dann, denn.