| Autor |
Beitrag |
Hidden
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: 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  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
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: 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 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: 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: 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; 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
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: Sa 05.04.08 13:41
Hidden 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
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: 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 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 05.04.08 13:49
BenBE hat folgendes geschrieben: | | o.ä. = oder ähnliches ??? Oder meinst Du o.e. (oben erwähnte)??? |
 Ja
BenBE 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: Hidden 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
|
Verfasst: Sa 05.04.08 14:29
BenBE 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
|
Verfasst: Sa 05.04.08 16:31
Hidden 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: 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; 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:
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 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
|
Verfasst: Sa 05.04.08 16:44
Grenzgaenger 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
      
Beiträge: 207
|
Verfasst: Sa 05.04.08 17:14
Hidden hat folgendes geschrieben: |
Mein Lehrer meinte jetzt aber letztens, jedes GoTo stelle eine Sicherheitslücke im Programm dar 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 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 05.04.08 17:41
Hi,
angenommen, ich habe einen Code folgender Form:
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; except end; 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
|
Verfasst: Sa 05.04.08 18:57
Hidden 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. 
|
|
Silas
      
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Sa 05.04.08 18:57
Grenzgaenger 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).
Grenzgaenger 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
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: Sa 05.04.08 19:24
|
|
Silas
      
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Sa 05.04.08 19:43
Yogu hat folgendes geschrieben: | Warum nicht so, wie Grenzgaenger 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
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Sa 05.04.08 22:05
Sauber ist das, was verständlich ist.
Hidden 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.
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| i := 0; While (i<10) and not found Do Begin k := 0; while (k<100) and not found Do Begin j := 0; while (j<50) and not found Do Begin ... if StopTheLoops (i,j,k) Then found := True; End End End |
oder
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.
Grenzgaenger 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.
Grenzgaenger 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:
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:
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 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 05.04.08 22:18
Hi,
Der Vorschlag von Grenzgänger ist - entschuldigung  - 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?
Luckie hat folgendes geschrieben: | Hidden 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.  |
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
ich bin ja über unterstützung froh, aber ganz so schlimm wäre es nach grenzgaenger doch nicht:
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
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: Sa 05.04.08 22:49
Hidden 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:
Delphi-Quelltext 1: 2: 3: 4: 5:
| try 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.
Hidden 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 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 05.04.08 23:06
Hi,
Delphi-Quelltext 1: 2: 3: 4: 5:
| try 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)?
Delphi-Quelltext 1: 2: 3: 4: 5:
| try except on not (E: EMyException) do raise; 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
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 06.04.08 10:04
Hidden hat folgendes geschrieben: | ich bin ja über unterstützung froh, aber ganz so schlimm wäre es nach grenzgaenger doch nicht:
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;
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| Try Try Foobar; Except On E:EMyException Do; On E:Exception Do Raise; End Except On E:Exception Do Begin ... 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:
Delphi-Quelltext 1: 2:
| RemoteConnection.Connect; RemoteConnection.SendData; |
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?
Delphi-Quelltext 1: 2:
| RemoteConnection.Connect; RemoteConnection.SendData; |
Ich kann also als schlampiger Programmierer mit Exceptions viel weniger Mist bauen.
_________________ Na denn, dann. Bis dann, denn.
|
|
|