Eingabefehler mit try except abfangen

[Teesäufer]

Hallo zusammen,

ich habe ein Problem: Ich habe ein Eingabefeld, bei dem man eine Zahl eingeben soll. Nun kommt es ja aber manchmal vor, dass man sich vertippt und versehentlich einen Text eingibt. Darum habe ich das in try except eingebettet. Nur leider hilft es nichts. So sieht das ganze aus:

try
ergebnis:=strtoint(Edit1.text);
except
label4.caption:='Fehlerhafte Eingabe'+ergebnistext;
end;

Trotzdem bricht das Programm mit einer Fehlermeldung ab, wenn ich einen Text eingebe. Was mache ich falsch?

[himitsu]

Zitat:

Zitat von Teesäufer (Beitrag 1511209)

Was mache ich falsch?

Noch etwas Anderes?

Was soll ergebnis im Except für einen Wert haben?
Sagt dir der Compiler denn nichts vonwegen "nicht initialisierte Variable"? Wenn doch, warum hörst du nicht auf ihn?
Was ist ergebnistext?

Und was heißt "bricht ab"?


Außerdem wird dir jeder zu Recht den A versohlen, wenn er beim Debuggen auf diesen Code stößt.
TryStrToInt
StrToIntDef

[Amateurprofi]

Zitat:

Zitat von Teesäufer (Beitrag 1511209)

Hallo zusammen,

ich habe ein Problem: Ich habe ein Eingabefeld, bei dem man eine Zahl eingeben soll. Nun kommt es ja aber manchmal vor, dass man sich vertippt und versehentlich einen Text eingibt. Darum habe ich das in try except eingebettet. Nur leider hilft es nichts. So sieht das ganze aus:

try
ergebnis:=strtoint(Edit1.text);
except
label4.caption:='Fehlerhafte Eingabe'+ergebnistext;
end;

Trotzdem bricht das Programm mit einer Fehlermeldung ab, wenn ich einen Text eingebe. Was mache ich falsch?

except
on E:Exception do label4.caption:='Fehlerhafte Eingabe'+ergebnistext;
end;

[himitsu]

Das ist egal, so lange E eh nicht verwendet wird.



Nur unter einer Annahme verhält es sich mit und ohne ON unterschiedlich.
Wenn E nicht als "Exception" deklariert ist,
bzw. wenn die "Exception" kein Exception-Objekt ist. (rein theoretisch möglich, da Exceptions kein Exception-Typ sein müssen, aber grundsätzlich sind sie es eigentlich immer)



Ach ja, der Grund für die Popo-Haue ist hier nicht,
dass die "eigentliche" Exception vernichtet und durch einen anderen Text ersetzt wird, aber nur weil es hier unter normalen Umständen nur eine Exception gibt, welche in etwa mit dem neun Text übereinstimmt.

Der Grund ist aber, dass hier eine sinnlose Exception als Prozessführtung benutzt wird,
also bösartig der Debugger angehalten wird, obwohl es genügend "ordentliche" Alternativen gibt. (selbst das uralte Val)
Exceptions sind Ausnahmen und kein Nomalverhalten.

Ich hab es schon erlebt, dass jemand sowas in einem OnPaint gemacht hat. Das macht im Debugger echt keinen Spaß und endet quasi in einer Endlosschleife.

[jaenicke]

Zitat:

Zitat von Teesäufer (Beitrag 1511209)

Nun kommt es ja aber manchmal vor, dass man sich vertippt und versehentlich einen Text eingibt.

Nicht, wenn du NumbersOnly bei dem Edit im Objektinspektor auf True setzt.

Ach ja, und MaxLength solltest du auch noch setzen, damit keine zu großen Zahlen eingegeben werden können.

[Delphi.Narium]

Oder TMaskEdit verwenden und dort eine passende Maske für die Eingabe hinterlegen?

[himitsu]

Windows/VCL hat nachgebessert.

Via Kopieren (Tastatur oder Menü) bekommt man nicht s Falsche mehr rein,
aber Programmseitig via Edit.Text:='abc', WN_SETTEXT usw. ist es aber denoch möglich. (z.B. beim Laden/Wiederherstellen der letzten Eingaben oder die Vorgabe aus der DFM)

Im FMX kann man bei der TNumberBox erstmals was Falsches eingeben/kopieren, aber im OnExit wird der Wert erst validiert und nur wenn gültig übernommen oder verworfen.


Also eine Prüfung im Code ist so oder so immer sicherheitshalber nötig.
Ja, während der Eingabe ist es natürlich nicht verkehrt, auch wenn es dort nicht immer zu 100% sicher ist.

[dummzeuch]

Zitat:

Zitat von Teesäufer (Beitrag 1511209)

Trotzdem bricht das Programm mit einer Fehlermeldung ab, wenn ich einen Text eingebe. Was mache ich falsch?

Glaskugel raushol:
Die Fehlermeldung kommt, wenn Du das Programm im Debugger laufen lässt?

Das ist normal, denn normalerweise will man solche Fehler im Debugger sehen. Dafür gibt es dann in diesem Dialog die Option die Execption zu ignoriren.

Wenn das Programm normal gestartet wird (also z.B. durch Doppelklick auf das Executable, greift der Exception-Handler und die Fehlermeldung (als Dialog) wird nicht angezeigt.

[himitsu]

Hier will niemand eine Exception sehen, also ist es wiedersinnig überhaupt Welche auszulösen und somit gibt es keinen Grund diesen Exception-Typ grundsätzlich programmweit auszublenden. :freak: