Autor Beitrag
Adryr
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 18

Win XP und Win7
Delphi 7
BeitragVerfasst: Mi 25.08.10 14:59 
HI
ich hab ein Problem mit dem Try Except Block in meinem Programm.

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
  try
    SollAnzSchiffe[2] := StrToInt(Edit1.Text);
    SollAnzSchiffe[3] := StrToInt(Edit2.Text);
    SollAnzSchiffe[4] := StrToInt(Edit3.Text);
  except
    ShowMessage('Bitte gib eine Zahl ein!');
  end;


es kommt keine Fehlermeldung vom COmpiler.

Wenn ich Zahlen eingebe, läuft auch alles normal. Aber wenn ein Buchstabe dabei ist, geht das Programm nicht in den Except teil rein.

kann mir jemand sagen, was ich falsch gemacht hab?
danke


Moderiert von user profile iconNarses: Topic aus VCL (Visual Component Library) verschoben am Mi 25.08.2010 um 23:19
JoelH
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Beiträge: 806
Erhaltene Danke: 17

Win10
Delphi Alexandria 11.2 Patch 1
BeitragVerfasst: Mi 25.08.10 15:12 
also ich kann den Fehler nicht nachvollziehen, bei mir funktioniert der Code.

Sagt denn der Debugger irgendwas?

_________________
mfg. Joel
mkinzler
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 4106
Erhaltene Danke: 13


Delphi 2010 Pro; Delphi.Prism 2011 pro
BeitragVerfasst: Mi 25.08.10 15:45 
Es fehlt auch das eigentlich Abfangen der Exception:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
  except
    on Exception do
        ShowMessage('Bitte gib eine Zahl ein!');
  end;


Man könnte natürlich auch TryStrToInt() verwenden

_________________
Markus Kinzler.
delfiphan
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2684
Erhaltene Danke: 32



BeitragVerfasst: Mi 25.08.10 16:24 
user profile iconAdryr hat folgendes geschrieben Zum zitierten Posting springen:
kann mir jemand sagen, was ich falsch gemacht hab?

Der Fehler oder das Missverständnis muss woanders liegen. Der Code ist so korrekt (wenn auch nicht schön).
Gausi
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 8554
Erhaltene Danke: 480

Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
BeitragVerfasst: Mi 25.08.10 16:32 
Tritt das unerwartete Verhalten auch auf, wenn du die Exe direkt startest, nicht über die IDE? Dafür gibt es dann nämlich eine Einstellung in den Delphi-Optionen, iirc irgendwas wie "Bei Sprach-Exceptions benachrichtigen".

_________________
We are, we were and will not be.
Critter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 328
Erhaltene Danke: 3

Windows 7
Delphi 7 Pro.
BeitragVerfasst: Mi 25.08.10 17:13 
Hi,
user profile iconmkinzler hat folgendes geschrieben Zum zitierten Posting springen:
Es fehlt auch das eigentlich Abfangen der Exception:

das stimmt so nicht, wenn du eh nur auf on Exception prüfst, dann kann man das Problemlos weglassen. Ich denke das user profile iconGausis Vermutung zutreffen wird und der Debugger sich hier nur einfach vordrängt. Also tatsächlich mal die Exe ohne Delphi Starten oder unter Tools->Optionen->Sprach-Exceptions verbieten, dass der Debugger in solchen Fällen reagiert.

critter

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)
Adryr Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 18

Win XP und Win7
Delphi 7
BeitragVerfasst: Mi 25.08.10 21:09 
also wenn ich die exe starte dann funktioniert das alles ohne probleme
aber wenn ich bei delphi die sprach exceptions ausmache kommt immernoch das gleiche problem:
"Im Projekt Projekt2.exe ist eine Exception der Klasse EConvertError aufgetreten. Meldung: "e ist keine gueltiger Integerwert.'..."
delfiphan
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2684
Erhaltene Danke: 32



BeitragVerfasst: Mi 25.08.10 21:33 
Da ist auch schon das Missverständnis. Der Debugger hält an um dir als Entwickler zu sagen, dass was schief gelaufen ist. Wenn du auf "Fortsetzen" klickst geht's weiter.
Wenn dir die extra Meldungen keinen Spass bereiten, kannst du das Programm auch ohne Debugging starten (Ctrl+Shift+F9).
Critter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 328
Erhaltene Danke: 3

Windows 7
Delphi 7 Pro.
BeitragVerfasst: Do 26.08.10 10:36 
Hi,
user profile icondelfiphan hat folgendes geschrieben Zum zitierten Posting springen:
Da ist auch schon das Missverständnis. Der Debugger hält an um dir als Entwickler zu sagen, dass was schief gelaufen ist.

richtig und hier kommen wir dann zum Thema sauberes Programmieren. Generell sollten Exceptions, nämlich die eine Ausnahme sein (wie der Name schon nahelegt ;)), also nur ein zusätzliches Sicherheitsnetz falls du einmal an einen möglichen Fehler nicht gedacht hast. Sie sollten nicht dazu verwendet werden Fehler abzufangen, mit denen du rechnest.
Deswegen macht es auch Sinn, wenn der Debuger dich explizit drauf hinweist, das eine Exception aufgetreten ist, dass ermöglicht dir nämlich eine Saubere Fehlerbehandlung für das Problem zu implementieren. Die Meldung kann man zwar abstellen (warum es bei dir nicht geht weiß ich nicht), sollte man aber eben nicht tun.

Dein Code user profile iconAdryr ist somit ein gutes Beispiel dafür wie man es nicht machen sollte. Sauberer wäre es z.B. gleich zu verhindern, dass etwas anderes als Ziffern in die Edit-Felder eingetragen wird. Dafür solltest du unzählige Beispiele hier im Forum finden. Alternativ kannst du auch Spin-Edits anstelle von Edits verwenden, die machen das von sich aus und du kannst sogar noch Ober- und Untergrenzen festlegen.

critter

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 26.08.10 11:02 
user profile iconCritter hat folgendes geschrieben Zum zitierten Posting springen:

richtig und hier kommen wir dann zum Thema sauberes Programmieren. Generell sollten Exceptions, nämlich die eine Ausnahme sein (wie der Name schon nahelegt ;)), also nur ein zusätzliches Sicherheitsnetz falls du einmal an einen möglichen Fehler nicht gedacht hast. Sie sollten nicht dazu verwendet werden Fehler abzufangen, mit denen du rechnest.

Mit welchen Fehlern kann man denn rechnen? Theoretisch kann man mit jeden Fehler rechnen. Deswegen bin ich nicht ganz deiner Meinung. Exceptions gehören zur strukturierten Ausnahmebehandlung und dienen unteranderem der Übersicht im Code. Beispiel:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
if fkt1 then
  if fkt2 then
    if fkt3 then
    else
  else
else

Das ist das übliche Konstrukt wenn man mit Rückgabewerten Arbeitet. Der Code ist unübersichtlich und erschwert die Fehlerbehandlung, da sie an im ganzen Code verstreut ist. Wenn die Funktionen Exceptions werfen, kann der Code so aussehen:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
try
  fkt1
  fkt2
  fkt3
except
  on E: Exception do
    // zentrale Fehlerbhandlung
end;

Das ist wesentlich übersichtlicher und es stört auch nicht den Lesefluss, wenn man den Code liest, was wiederum zum leichteren Verständnis beiträgt.
Tankard
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Administrator
Beiträge: 217
Erhaltene Danke: 96



BeitragVerfasst: Do 26.08.10 11:31 
Hallo,

ich muss mich da Luckie anschliessen, selbst wenn du via onKeyPress die Eingaben filterst, heisst das noch lange nicht das im Edit Feld keine Buchstaben stehen. Schlaue User nutzen einfach mal Copy/Paste und schon steht der Mist drin. Kann man natürlich auch die abfangen und es ist auch richtig, dass wir meistens eh nur Fehlerbehandlungsroutinen schreiben, weil die Softwareuser uns nur ärgern wollen. 60 Codezeilen um Fehler die ich auch mit einer Exception mit nur 6 Zeilen abfangen kann, dann zieh ich die Exception einfach vor. Heisst natuerlich nicht das man sowas wie hier machen sollte:


ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
try
  application.run;
except
  applicaation.Terminate;
end;


das würde selbst ich als unsauber bezeichnen, obwohl ja alle Fehler abgefangen werden ;)
JoelH
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Beiträge: 806
Erhaltene Danke: 17

Win10
Delphi Alexandria 11.2 Patch 1
BeitragVerfasst: Do 26.08.10 11:42 
Ich stehe da auch eher auf der Seite von Luckie.

Da der Block nur gesamtgültig ist und Einzelfehler auf jeden Fall das Weiterlaufen des Programms verhindern, kann man sie der Übersichtlichkeit auch in einem Block zusammenfassen. Das erhöht einfach die Codelesbarkeit, vor allem wenn jemand fremdes mal den Code debuggen muss.

_________________
mfg. Joel
Lossy eX
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 1048
Erhaltene Danke: 4



BeitragVerfasst: Do 26.08.10 12:04 
Ich denke so etwas kann man auch nicht pauschal sagen. Meiner Meinung nach kommt es immer darauf an was der Code machen soll und wie Benutzerfreundlich es sein soll. Bei 20 Feldern zu sagen "Gibt eine Zahl ein" hilft nicht. Da sollte man schon sagen. Gib eine Zahl in Feld 17 ein. Und dann kommt man nicht umher die Felder einzeln zu überprüfen. Ist aber dann durchaus nötig um dem Benutzer zu helfen / zu unterstützen. Wie man dann den Code strukturiert hängt aber auch wieder vom dem Ab was man mit dem Code anstellen will. Vielleicht muss man dann eher C Like arbeiten und nicht so extrem verschachteln. Also eher so.
ausblenden Delphi-Quelltext
1:
2:
if not fkt1 then
  exit;


Zu den Exception: Das sehe ich allerdings ähnlich wie critter. Wenn man einen Fall hat an dem zu einer gewissen Wahrscheinlichkeit falsche Dinge aufschlagen können ist es keine Ausnahme mehr sondern sollte sauber berücksichtigt werden. In dem obrigen Fall mag das vielleicht gerade noch okay sein. Aber wenn man solche Strukturen an Codestellen benutzt die regelmäßig aufgerufen werden, dann macht das keinen Spaß mehr so etwas in der IDE laufen zu lassen. Ich hatte so einen Code mal. Da wurde mit StrToInt überprüft ob der aus einer Datei eingelesene Text ein Integer ist oder ob noch weitere Formate überprüft werden sollten. Hat im Endeffekt dazu geführt, dass ich die Exception im Debugger unterdrücken musste. Was dann aber echte Fehler an anderen Stellen ebenfalls unterdrückt hat und man sich dann nur dumm und dämlich suchen musste warum der Code denn jetzt nicht funktioniert. Es kommt halt immer drauf an wo und wie der Code eingesetzt wird. Allerdings sollte man als Einsteiger wohl eher dazu tendieren Fehler zu berücksichtigen als sie zu unterdrücken. Denn sonst dürfte man wohl eher der Versuchung unterliegen so eine Art auch an anderen Stellen zu verwenden. Und das kann verherend sein. Meine Meinung.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.
mkinzler
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 4106
Erhaltene Danke: 13


Delphi 2010 Pro; Delphi.Prism 2011 pro
BeitragVerfasst: Do 26.08.10 12:15 
In diesem Fall würde ich aber keine Try..Except sondern ein TryStrToInt() pro Feld verwenden

_________________
Markus Kinzler.
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 26.08.10 12:16 
Im Grunde genommen ist jeder Fehler eine Ausnahme, denn der normale Programmablauf sollte ja ohne Fehler erfolgen. Aber das können wir in der WG-Küche ausdiskutieren. ;)
Critter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 328
Erhaltene Danke: 3

Windows 7
Delphi 7 Pro.
BeitragVerfasst: Do 26.08.10 12:33 
Hi,
user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Mit welchen Fehlern kann man denn rechnen? Theoretisch kann man mit jeden Fehler rechnen.

richtig. Theoretisch geht das in der Praxis klappt das aber nicht immer, deswegen ist Try-Except als Sicherheitsnetz ja auch so Praktisch.


user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Deswegen bin ich nicht ganz deiner Meinung. Exceptions gehören zur strukturierten Ausnahmebehandlung und dienen unteranderem der Übersicht im Code. Beispiel:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
if fkt1 then
  if fkt2 then
    if fkt3 then
    else
  else
else


Das müsste so aussehen ;) :
ausblenden Delphi-Quelltext
1:
2:
3:
if fkt1 then
  if fkt2 then
    if fkt3 then

Denn in deinen Try Except Beispiel hast du auch keine Else Behandlung. Aber Generell ist das richtig, dass es häufiger zu tieferen Verschachtelungen kommt, wenn man mehrere Fehlerüberprüfungen machen muss. Ich persönlich finde das aber gerade nicht unübersichtlich, sondern im Gegenteil, wenn ich etwas Debuggen muss eher hilfreich, denn je nach dem wo ich in den Verschachtelungen lang Steppe kann ich recht gut sehen was geht und was nicht. Meist muss ich aber nicht einmal steppen, da der Debugger mich beim Auftreten einer Exception schon an einer passenden Stelle in der Verschachtelung abläd, so dass ich schon aufgrund der Position gut erkennen kann, wo das Problem liegen müsste.

user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Das ist das übliche Konstrukt wenn man mit Rückgabewerten Arbeitet. Der Code ist unübersichtlich und erschwert die Fehlerbehandlung, da sie an im ganzen Code verstreut ist. Wenn die Funktionen Exceptions werfen, kann der Code so aussehen:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
try
  fkt1
  fkt2
  fkt3
except
  on E: Exception do
    // zentrale Fehlerbhandlung
end;

Ich finde die Fehlerbehandlung ist hier eher erschwert, da ich, sofern eine Exception auftritt nicht ohne weiteres sagen kann, ob fkt1, fkt2 oder fkt3 hierfür verantwortlich ist.

Das kann übrigens auch im Punkto Usibility interessant sein. Bleiben wir doch der Einfachheit halber mal bei user profile iconAdryr Beispiel:

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
  try
    SollAnzSchiffe[2] := StrToInt(Edit1.Text);
    SollAnzSchiffe[3] := StrToInt(Edit2.Text);



    SollAnzSchiffe[4] := StrToInt(Edit3.Text);
  except
    ShowMessage('Bitte gib eine Zahl ein!');
  end;

Hier wird der user darauf hingewiesen, das er irgendwo in den drei Feldern eine Fehleingabe gemacht hat. Ich finde es viel Nutzer freundlicher, wenn er dem user auch drauf hinweisen würde in welchem Feld die Fehleingabe gemacht hat, denn eventuell nimmt er gar nicht war, das er im Edit2 nicht '123' sondern ' 123' stehen hat. Am elegantesten fände ich es in diesem Fall, wenn das Feld ihn schon beim eingeben des Leerzeichens darauf hinweisen würde das dieses an dieser Stelle nicht erlaubt ist (ich lasse Felder in dem Moment gerne piepen und rot werden).

Ich möchte hier aber nicht zu absolut werden. Natürlich gibt es Fälle in denen eine reine Behandlung per Try-Except akzeptabel oder gar sinnvoll ist, ich bin nur überzeugt, das es die wenigsten Situationen sind und auch in diesen sollte dann möglichst detailliert auf die Art der (erwarteten) Exception reagiert werden z.B.:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
procedure Rechne;

  Procedure ShowError(OwnText : String; E : Exception);
  begin
    ShowMessage(OwnText + #13#10#13#10 + 'Systemmeldung: ' + E.Message);
  end;

begin
  Try
    Label1.Caption := FloatToStr(StrToInt(Edit1.Text) / StrToInt(Edit2.Text));
  Except
    on E : EIntOverflow do
      ShowError('Mindestens eine der Verwendeten Zahlen ist zu Groß.', E);
    on E: EZeroDivide do
      ShowError('Der zweite Wert darf nicht Null sein, da es nicht möglich ist durch Null zu teilen.', E);
    on E: Exception do
      ShowError('Ein unbekannter Fehler ist aufgetreten.' , E);
  End;
end;


user profile iconTankard hat folgendes geschrieben Zum zitierten Posting springen:
selbst wenn du via onKeyPress die Eingaben filterst, heisst das noch lange nicht das im Edit Feld keine Buchstaben stehen. Schlaue User nutzen einfach mal Copy/Paste und schon steht der Mist drin.

Natürlich, wenn man es macht muss man es richtig machen, dass widerspricht meinen Aussagen aber nicht und ich habe OnKeyPress (OnKeyDown) aus dem Grund auch nicht erwähnt. Warum ich aber solche Lösungen bevorzuge und es auch für sauberer halte eben möglichst keine End of pipe Lösungen zu nutzen habe ich oben beschrieben.

critter

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 26.08.10 14:04 
user profile iconCritter hat folgendes geschrieben Zum zitierten Posting springen:

user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Deswegen bin ich nicht ganz deiner Meinung. Exceptions gehören zur strukturierten Ausnahmebehandlung und dienen unteranderem der Übersicht im Code. Beispiel:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
if fkt1 then
  if fkt2 then
    if fkt3 then
    else
  else
else


Das müsste so aussehen ;) :
ausblenden Delphi-Quelltext
1:
2:
3:
if fkt1 then
  if fkt2 then
    if fkt3 then

Denn in deinen Try Except Beispiel hast du auch keine Else Behandlung.

Doch, der Except-Zweig. Wenn, Fehler, dann Exception und Fehlerbehandlung.

Zitat:
Ich persönlich finde das aber gerade nicht unübersichtlich,

Alter Quellcode von mir:
ausblenden volle Höhe 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:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
function AssertTakeOwnerShip(var TokenHandle: THandle): Boolean;
var
  TakeOwnershipValue: TLargeInteger;
  TokenPrivileges: TOKEN_PRIVILEGES;
  Return: DWORD;
begin
  Result := LookupPrivilegeValue(nil'SeTakeOwnershipPrivilege', TakeOwnershipValue);
  if Result then
  begin
    TokenPrivileges.PrivilegeCount := 1;
    TokenPrivileges.Privileges[0].Luid := TakeOwnershipValue;
    TokenPrivileges.Privileges[0].Attributes := SE_PRIVILEGE_ENABLED;
    AdjustTokenPrivileges(TokenHandle, False, TokenPrivileges, sizeof(TOKEN_PRIVILEGES), nil, Return);
  end;
end;

var
  TokenHandle: THandle = 0;
  SecurityDescriptor: SECURITY_DESCRIPTOR;

label ENDPROG;

begin
  Writeln(APPNAME + ' - ' + VER);
  Writeln(COPYRIGHT);
  Writeln(LF);

  if ParamCount < 1 then
  begin
    Writeln(rsNoFile);
    goto ENDPROG;
  end
  else if ParamCount >= 2 then
  begin
    Writeln(rsTooManyParams);
    goto ENDPROG;
  end;

  Filename := ParamStr(1);
  if (Filename[1] = '-'or (Filename[1] = '/'then
    Filename := copy(Filename, 2, length(Filename));

  if FileExists(Filename) then
  begin
    if InitVars then
    begin
      if GetTokenHandle(TokenHandle) then
      begin
        // Attempt to put a NIL Dacl on the object
        InitializeSecurityDescriptor(@SecurityDescriptor, SECURITY_DESCRIPTOR_REVISION);
        if SetSecurityDescriptorDacl(@SecurityDescriptor, True, NIL, False) then
        begin
          if SetFileSecurity(@Filename[1], DACL_SECURITY_INFORMATION, @SecurityDescriptor) then
          begin
            Writeln(rsSuccess);
            goto ENDPROG;
          end

          else  // Attempt to make the Adminstrator the owner
          begin
            if SetSecurityDescriptorOwner(@SecurityDescriptor, AliasAdminSID, False) then
            begin
              if SetFileSecurity(@Filename[1], OWNER_SECURITY_INFORMATION, @SecurityDescriptor) then
              begin
                Writeln(rsSuccess);
                goto ENDPROG;
              end
              else  // Assert TakeOwnerShip privileges and try again
              begin
                if AssertTakeOwnerShip(TokenHandle) then
                begin
                  if SetFileSecurity(@Filename[1], OWNER_SECURITY_INFORMATION, @SecurityDescriptor) then
                  begin
                    Writeln(rsSuccess);
                    goto ENDPROG;
                  end
                  else  // Try to put a benign Dacl onto the file again
                  begin
                    if SetFileSecurity(@Filename[1], DACL_SECURITY_INFORMATION, @SecurityDescriptor) then
                    begin
                      Writeln(rsSuccess);
                      goto ENDPROG;
                    end
                    else
                    begin
                      Writeln(rsError);
                      goto ENDPROG;
                    end;
                  end;
                end
                else
                begin
                  Writeln(rsNoPrivOwnership);
                  goto ENDPROG;
                end;
              end;
            end;
          end;
        end
        else
        begin
          Writeln(rsNoSecDes);
          goto ENDPROG;
        end;
      end
      else
      begin
        Writeln(rsNoToken);
        goto ENDPROG;
      end;
    end
    else
    begin
      Writeln(rsNoSID);
      goto ENDPROG;
    end;
  end
  else
    Writeln(rsFileNotExists);

Können wir noch mal über die Übersichtlichkeit reden? ;)

Zitat:
da der Debugger mich beim Auftreten einer Exception schon an einer passenden Stelle in der Verschachtelung abläd, so dass ich schon aufgrund der Position gut erkennen kann, wo das Problem liegen müsste.

Also sind wir jetzt doch wieder bei Exceptions? Wenn du sie zum Debuggen nutzt, warum dann nicht auch zur Fehlerbehandlung?

Zitat:
Ich finde die Fehlerbehandlung ist hier eher erschwert, da ich, sofern eine Exception auftritt nicht ohne weiteres sagen kann, ob fkt1, fkt2 oder fkt3 hierfür verantwortlich ist.

Warum nicht? Der Debugger steigt doch genau an der Stelle aus, wo die Exception auftritt. Das hast du oben noch selber gesagt.
Critter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 328
Erhaltene Danke: 3

Windows 7
Delphi 7 Pro.
BeitragVerfasst: Do 26.08.10 14:52 
Hi,
user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Können wir noch mal über die Übersichtlichkeit reden? ;)

nein, nicht bei dem Quelltext. Du musst zugeben an dem trägt mehr zur Unübersichtlichkeit bei als die Vierschachtelung durch Sicherheitsabfragen. Man könnte alle Gotos raus schmeißen indem man den restlichen Code einfach in eine eigene Methode Kapselt welche man vor der Methode "ENDPROG" aufruft. Auch ist es sicher keine Schlechte Idee, wenn man viele Überprüfungen hat, diese am Anfang zu machen und erst dann mit der Arbeit zu beginnen wenn alles stimmt. In Falles deines Codes hätte es auch viel zur Übersichtlichkeit Beigetragen, wenn du den Codeschnipzel

ausblenden Delphi-Quelltext
1:
2:
if SetFileSecurity(@Filename[1], OWNER_SECURITY_INFORMATION, @SecurityDescriptor) then
  Writeln(rsSuccess);


welcher sich Ständig wiederholt in eine eigene Funktion ausgelagert hättest.

Schlecht Designten Code kann man bei jeder Art der Fehlerbehandlung finden. Das hat mit dieser als solcher wenig zu tun.

user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Zitat:
da der Debugger mich beim Auftreten einer Exception schon an einer passenden Stelle in der Verschachtelung abläd, so dass ich schon aufgrund der Position gut erkennen kann, wo das Problem liegen müsste.

Also sind wir jetzt doch wieder bei Exceptions? Wenn du sie zum Debuggen nutzt, warum dann nicht auch zur Fehlerbehandlung?

Sorry, hier war ich zu Unpräzise, das war im Zusammenhang mit der Aussage

user profile iconCritter hat folgendes geschrieben Zum zitierten Posting springen:
Deswegen macht es auch Sinn, wenn der Debuger dich explizit drauf hinweist, das eine Exception aufgetreten ist, dass ermöglicht dir nämlich eine Saubere Fehlerbehandlung für das Problem zu implementieren.

Wie ich erwähnte können Fehler auftreten an die man schlichtweg nicht Gedacht hat (weshalb man ja auch Try-Except als Sicherheitsnetz verwenden soll). Wenn dies passiert bietet die Position an der der Debugger hält schon hinweise dafür was man übersehen hat, das muss nicht so sein, aber es kommt oft genug vor.


user profile iconLuckie hat folgendes geschrieben Zum zitierten Posting springen:
Zitat:
Ich finde die Fehlerbehandlung ist hier eher erschwert, da ich, sofern eine Exception auftritt nicht ohne weiteres sagen kann, ob fkt1, fkt2 oder fkt3 hierfür verantwortlich ist.

Warum nicht? Der Debugger steigt doch genau an der Stelle aus, wo die Exception auftritt. Das hast du oben noch selber gesagt.

Ja, bei der Fehlersuche ist das richtig, bei der Fehlerbehandlung, also der Entscheidung wie das Programm mit dem Fehler umgeht/Was es dem User meldet, hilft das aber nicht. Deine Exception kann nur Sagen in fkt1 oder fkt2 oder fkt3 ist ein Fehler aufgetreten. Wenn du vorher überprüft ob alle Bedingungen für die Funktionen erfüllt sind (bevorzugt) oder im Nachhinein wenigstens jeden einzelnen Aufruf auf Fehler überprüfst, kannst du viel dedizierter auf die Probleme reagieren.

critter

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)
Adryr Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 18

Win XP und Win7
Delphi 7
BeitragVerfasst: Do 26.08.10 21:44 
danke
ich hab das problem jetzt mit TryStrToInt geloest

mfg Adryr
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 26.08.10 22:01 
user profile iconCritter hat folgendes geschrieben Zum zitierten Posting springen:
Deine Exception kann nur Sagen in fkt1 oder fkt2 oder fkt3 ist ein Fehler aufgetreten. Wenn du vorher überprüft ob alle Bedingungen für die Funktionen erfüllt sind (bevorzugt) oder im Nachhinein wenigstens jeden einzelnen Aufruf auf Fehler überprüfst, kannst du viel dedizierter auf die Probleme reagieren.

Nun ja, die Funktionen sollten natürlich schon aussagekräftige Exceptions werfen.