| Autor |
Beitrag |
Adryr
      
Beiträge: 18
Win XP und Win7
Delphi 7
|
Verfasst: Mi 25.08.10 14:59
HI
ich hab ein Problem mit dem Try Except Block in meinem Programm.
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 Narses: Topic aus VCL (Visual Component Library) verschoben am Mi 25.08.2010 um 23:19
|
|
JoelH
      
Beiträge: 806
Erhaltene Danke: 17
Win10
Delphi Alexandria 11.2 Patch 1
|
Verfasst: 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
      
Beiträge: 4106
Erhaltene Danke: 13
Delphi 2010 Pro; Delphi.Prism 2011 pro
|
Verfasst: Mi 25.08.10 15:45
Es fehlt auch das eigentlich Abfangen der Exception:
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
      
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Mi 25.08.10 16:24
Adryr hat folgendes geschrieben : | | 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
      
Beiträge: 8554
Erhaltene Danke: 480
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: 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
      
Beiträge: 328
Erhaltene Danke: 3
Windows 7
Delphi 7 Pro.
|
Verfasst: Mi 25.08.10 17:13
Hi,
mkinzler hat folgendes geschrieben : | | 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 Gausis 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 
      
Beiträge: 18
Win XP und Win7
Delphi 7
|
Verfasst: 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
      
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: 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
      
Beiträge: 328
Erhaltene Danke: 3
Windows 7
Delphi 7 Pro.
|
Verfasst: Do 26.08.10 10:36
Hi,
delfiphan hat folgendes geschrieben : | | 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 Adryr 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
|
Verfasst: Do 26.08.10 11:02
|
|
Tankard
      

Beiträge: 217
Erhaltene Danke: 96
|
Verfasst: 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:
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
      
Beiträge: 806
Erhaltene Danke: 17
Win10
Delphi Alexandria 11.2 Patch 1
|
Verfasst: 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
      
Beiträge: 1048
Erhaltene Danke: 4
|
Verfasst: 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.
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
      
Beiträge: 4106
Erhaltene Danke: 13
Delphi 2010 Pro; Delphi.Prism 2011 pro
|
Verfasst: 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
|
Verfasst: 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
      
Beiträge: 328
Erhaltene Danke: 3
Windows 7
Delphi 7 Pro.
|
Verfasst: Do 26.08.10 12:33
Hi,
Luckie hat folgendes geschrieben : | | 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.
Luckie hat folgendes geschrieben : | Deswegen bin ich nicht ganz deiner Meinung. Exceptions gehören zur strukturierten Ausnahmebehandlung und dienen unteranderem der Übersicht im Code. Beispiel:
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  :
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.
Luckie hat folgendes geschrieben : | 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:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| try fkt1 fkt2 fkt3 except on E: Exception do 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 Adryr Beispiel:
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.:
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; |
Tankard hat folgendes geschrieben : | | 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
|
Verfasst: Do 26.08.10 14:04
Critter hat folgendes geschrieben : |
Luckie hat folgendes geschrieben : | Deswegen bin ich nicht ganz deiner Meinung. Exceptions gehören zur strukturierten Ausnahmebehandlung und dienen unteranderem der Übersicht im Code. Beispiel:
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 :
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:
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 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 begin if SetSecurityDescriptorOwner(@SecurityDescriptor, AliasAdminSID, False) then begin if SetFileSecurity(@Filename[1], OWNER_SECURITY_INFORMATION, @SecurityDescriptor) then begin Writeln(rsSuccess); goto ENDPROG; end else begin if AssertTakeOwnerShip(TokenHandle) then begin if SetFileSecurity(@Filename[1], OWNER_SECURITY_INFORMATION, @SecurityDescriptor) then begin Writeln(rsSuccess); goto ENDPROG; end else 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
      
Beiträge: 328
Erhaltene Danke: 3
Windows 7
Delphi 7 Pro.
|
Verfasst: Do 26.08.10 14:52
Hi,
Luckie hat folgendes geschrieben : | 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
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.
Luckie hat folgendes geschrieben : | | 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
Critter hat folgendes geschrieben : | | 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.
Luckie hat folgendes geschrieben : | | 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 
      
Beiträge: 18
Win XP und Win7
Delphi 7
|
Verfasst: Do 26.08.10 21:44
danke
ich hab das problem jetzt mit TryStrToInt geloest
mfg Adryr
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Do 26.08.10 22:01
Critter hat folgendes geschrieben : | | 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.
|
|
|