JAVA = doof -> String nicht gleich Int

[M@tes]

Java is strutzdoof, find ich^^ Da find ich selbst Perl noch besser ;D :P
Egal. Geht um folgenden Befehl:
Page = TextField_Nr.getText();

Page ist am Anfang mit int mit dem Wert 0 gesetzt worden.
Nun mekert Eclipse was von cannot convert from String to int.
getText gibt ein String zurück, aber da sollen später nur Zahlen rein..
Wie löse ich hier das int/ String dilema?? :confused: :frown:

[Unfug]

Integer.valueOf() ??

[UliBär]

Das ist nicht Dein Ernst oder? :biggrin:

Page = Integer.parseInt(TextField_Nr.getText());

[Magnum]

Das ist nicht Dein Ernst oder? :biggrin:

Page = Integer.parseInt(TextField_Nr.getText());
Besser gleich noch ein try-catch-Block drumm rum. Für alle Fälle.
try {
Page = Integer.parseInt(TextField_Nr.getText());
} catch (NumberFormatException nfe) {
Page = 0;
}

Und so doof ist Java auch wieder nicht! Es sagt dir hier nur expilzit, dass dieser Cast so nicht automatisch gemacht wird. Das ist nur so, damit man hiermit aus Versehen keinen Fehler baut, sondern es wirklich mit Absicht einbauen muss! (expliziter Cast? Weiß grad net, ob das von Int zu String geht!) Und außerdem dürfte dies wesentlich performanter als die Lösung von Perl sein!

[UliBär]

(...) Weiß grad net, ob das von Int zu String geht! (...) String Zahl = Integer.toString(1234);

[Magnum]

String Zahl = Integer.toString(1234);
Das meinte ich net! Das geht so String Zahl = "" + 1234; IMO genauso gut! Falls mir einer den Unterschied dazwischen sagen kann, dann bitte, nur zu!

Was ich meinte war, ob ein normaler Cast ala: String Zahl = (String)1234; funktioniert?

[UliBär]

Das meinte ich net! Das geht so String Zahl = "" + 1234; IMO genauso gut! Falls mir einer den Unterschied dazwischen sagen kann, dann bitte, nur zu!

Was ich meinte war, ob ein normaler Cast ala: String Zahl = (String)1234; funktioniert?Das erste funktioniert, da es sich um den Verkettungsoperator für Strings (und nicht die Addition) handelt. Der ruft für Nicht-String-Datentypen die entsprechende x.toString()-Funktion auf und wandelt den Datentyp in einen String.

Das zweite geht nicht, da die Datentypen nicht skalar sind.

[M@tes]

Jo is klar.. War auch nich wirklich ernst gemeint. Hat mich nurn wenig aufgeregt, weil ichs von Perl her eben nich kenne ;D
Hat mit dem Try/ Catch gut funktioniert.

Brauchte ich für eine Schulaufgabe. Naja war nicht die Aufgabe selber. Hab halt ausserhalb vom Stoff spasseshalber weiter rumprobiert und entsprechend fehlten mir aufeinmal paar wichtige Infos.. :redface:
(Navigation für ein Datenbankprogramm. Mit Button Vorwärts und Rückwärts. Aber wieso lang blättern, wenn man auch schnell die Zahl eingeben kann?? :wink: )

[gereggter Gast]

Besser gleich noch ein try-catch-Block drumm rum. Für alle Fälle.
try {
Page = Integer.parseInt(TextField_Nr.getText());
} catch (NumberFormatException nfe) {
Page = 0;
}

Und so doof ist Java auch wieder nicht! Es sagt dir hier nur expilzit, dass dieser Cast so nicht automatisch gemacht wird. Das ist nur so, damit man hiermit aus Versehen keinen Fehler baut, sondern es wirklich mit Absicht einbauen muss! (expliziter Cast? Weiß grad net, ob das von Int zu String geht!) Und außerdem dürfte dies wesentlich performanter als die Lösung von Perl sein!Falls eine Exception geschmissen wird, wäre dies sehr teuer. Wäre es schneller, wenn man vorher per regulärem Ausdruck überprüft, ob es sich bei dem String um einen Integerwert handelt? :uponder:
(Kommt natürlich auch auf die Häufigkeit an, wie oft es sich um keine Zahl handelt. Aber wenn z.B. jeder fünfte String keine Zahl ist.)

[ScottManDeath]

In .Net gibts ne Methode die bool zurückliefert ob ein String eine gültige Zahl ist, oder nicht. Da Java schon länger am Markt ist, sollte sowas dort auch vorhanden sein.

[Johnny]

In .Net gibts ne Methode die bool zurückliefert ob ein String eine gültige Zahl ist, oder nicht.
:| Und die wäre? Wenn du IsNumeric() meinst, dann ist es eine VB-spezifische Methode und keine .NET-Methode.

[Gast]

Falls eine Exception geschmissen wird, wäre dies sehr teuer. Wäre es schneller, wenn man vorher per regulärem Ausdruck überprüft, ob es sich bei dem String um einen Integerwert handelt?Um Gottes Willen...Nein! Das Werfen der Exception ist nicht so teuer, wo es in Mythen und Legenden gerne behauptet wird. Das vorher, und dann auch noch mit RegEx, zu prüfen, ist mit Kanonen auf Spatzen geschossen.

[Spasstiger]

Jo is klar.. War auch nich wirklich ernst gemeint. Hat mich nurn wenig aufgeregt, weil ichs von Perl her eben nich kenne ;D
Hat mit dem Try/ Catch gut funktioniert.
Ein Integer-Objekt ist nunmal kein String-Objekt. Du sagst ja auch nicht Apfel = Birne oder Backofen = Kühlschrank. Den Inhalt aus dem Kühlschrank musst du schon von Hand in den Backofen packen.

[ScottManDeath]

:| Und die wäre? Wenn du IsNumeric() meinst, dann ist es eine VB-spezifische Methode und keine .NET-Methode.

TryParse (http://msdn2.microsoft.com/en-us/library/f02979c7.aspx)

Laufzeitumgebungen wie Java oder .Net haben Support für Excpeptions auf Laufzeitebene, dadurch halten sich die Kosten dafür in Grenzen.

[gereggter Gast]

Um Gottes Willen...Nein! Das Werfen der Exception ist nicht so teuer, wo es in Mythen und Legenden gerne behauptet wird. Das vorher, und dann auch noch mit RegEx, zu prüfen, ist mit Kanonen auf Spatzen geschossen.Es ist mir völlig neu, dass Exception-Handling billig ist. :O

Zumindest ging ich bisher immer davon aus, dass man Exceptions verhinden soll, statt sie als If-Else-Bedingung zu missbrauchen.
Darum habe ich selbst mal einen Test durchgeführt, um dir das Gegenteil von deiner Aussage zu beweisen. :smile:


public class ExceptionTest {
private final static String[] test = new String[] {"- 1", "- 2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "0"};
private final static int count = 500000;
private final static Pattern p = Pattern.compile("-?\\d+");

private static long testException() {
long start = System.currentTimeMillis();
long badNumbers = 0;
for(int j = count; --j > 0;) {
for(int i = test.length; --i >= 0;) {
try {
int testnummer = Integer.valueOf(test[i]);
}
catch(NumberFormatException e) {
++badNumbers;
}
}
}
return System.currentTimeMillis() - start;
}

private static long testRegex() {
long start = System.currentTimeMillis();
long badNumbers = 0;
for(int j = count; --j > 0;) {
for(int i = test.length; --i >= 0;) {
if(p.matcher(test[i]).matches()) {
int testnummer = Integer.valueOf(test[i]);
}
else
++badNumbers;
}
}
return System.currentTimeMillis() - start;
}

public static void main(String[] argv) {
System.out.println("Test:");
System.out.flush();
// Vorlauf
testException();
testRegex();
// Testlauf
long excep = testException();
long regex = testRegex();

System.out.println("Regex: "+regex);
System.out.println("Excep: "+excep);
}
}

0 falsche Zahlen (Regex-Test, Exception): 3.55 Sekunden, 0.45 Sekunden
1 falsche Zahlen (Regex-Test, Exception): 3.6 Sekunden, 2.45 Sekunden
2 falsche Zahlen (Regex-Test, Exception): 3.45 Sekunden, 4.55 Sekunden

Je mehr falsche Zahlen zu erwarten sind, umso langsamer wird das Programm, weil die Exceptions alle gefangen werden müssen.
Ca. ab 15% zu erwartener falscher Zahlen dürfte sich ein vorheriger Regex-Test lohnen. Wenn man sicher sein kann, dass es sich vorwiegend um richtige Zahlen handelt, kann man die Exception-Variante verwenden.
Soviel dazu, dass das Werfen einer Exception nicht so teuer sei, wie es in Mythen und Legenden gerne behauptet wird. :rolleyes:

[Gast]

Ja, aber hier geht um ein Eingabefeld, wo er Zahlen eintippt (wenn ich das richtig verstanden habe). Da tippt er nicht eine Million mal Unfug in Folge ein und selbst wenn, ist es völlig egal, ob die Prüfung dann 3 oder 4 Sekunden dauert. So schnell kann er gar nicht tippen.
Hier vorher mittels RegEx zu prüfen, anstatt die Exception dies für sich erledigen zu lassen, macht keinerlei Sinn. Er erschwert nur die Lesbarkeit des Codes und ist nicht einmal Microoptimizing.
Ich gebe die allerdings recht, dass, wenn die Exception zur Regel wird, ihr vermeiden sinnvoll ist. Dann ist es aber auch keine Exception (=Ausnahme) mehr sondern eben die Regel. Für diesen Fall würde ich zwar dann auch keine RegEx benutzen sondern mir lieber einen Dreizeiler zur Überprüfung selber bauen, aber egal.

[Gast]

P.S.: Das ganze ausgeführt auf einem P4 unter Java6 und um eine Methode zur Zahlenerkennung ohne RegEx ergänzt:

Regex: 4469
Excep: 5187
Self: 1062

Also bevor man da versucht, mit RegEx die Exception zu verhindern, würde ich gleich beides verhindern.

[EgonOlsen]

Soviel dazu, dass das Werfen einer Exception nicht so teuer sei, wie es in Mythen und Legenden gerne behauptet wird. :rolleyes:Ein bisschen Klugscheißerei am Rande, auch wenn es hier nicht wirklich was zur Sache tut: Das Werfen und Fangen einer Exception ist nicht "teuer". Was im Verhältnis wesentlich teurer ist, ist das Instanziieren der Exception, weil dafür der ganze Stacktrace zusammengebaut werden muss.
In manchen Fällen kann man die Exception vorgenerieren und mehrmals dieselbe werfen. In diesem Fall geht das natürlich nicht.

Ach ja: Andere CPUs, andere Sitten. Auf einem Core2Duo@3Ghz sieht es so aus ("Chars" ist meine eigene isNumeric()-Methode ohne reguläre Ausdrücke):

Chars: 266
Excep: 1110
Regex: 1421