Gemeiner, kleiner Fehler, der sich da in eines meiner Skripte geschlichen hat:
var value = parseInt(input);
if (typeof value === 'number') {
doSomething(value);
}
Blöd, wenn doSomething nur mit richtigen Zahlwerten arbeiten kann: ParseInt liefert im Fehlerfall NaN. Und NaN hat einige interessante Verhaltensweisen:
typeof NaN // 'number' NaN == NaN // false
Richtig prüfen: isNaN
isNaN(parseInt('42')) // false
isNaN(parseInt('zweiundvierzig')) // true
Somit:
var value = parseInt(input);
if (!isNaN(value)) {
doSomething(value);
}
In der Tat ist dieses NaN eine merkwürdige Sache. Braucht man sowas?
Wohl kaum. In anderen Sprachen ist es ja auch nicht üblich und ich sehe keinen Mehrwert. Eine Null-Rückgabe hätte es wohl auch getan. Aber das sind so typische Altlasten, die man nie wieder los wird.
Bei parseInt ist es auch ratsam die Basis 10 zu benutzen, sonst kann es zu unerwünschten Verhalten kommen:
var n = parseInt('015');alert(n);
Kennst du einen Browser der das falsch interpretiert? Auch die Mozillaseite warnt vor unerwartetem Verhalten, sagt aber auch, dass der ECMA-Standard hier eindeutig ist. Würde mich interessieren ob das wirklich noch ein Problem ist oder nur ein Mythos der sich aufgrund von Problemen beim IE 3 bis heute gehalten hat.
Ich hatte auch schon mal das Problem. Gerade, wenn die Eingabe vom Benutzer kommt, interessiert ihn das doch nicht, ob da eine 0 vor kommt ….
Heißt das, dass du schon mal den konkreten Fall hattest, in dem der Browser wegen ner 0 davor in den Oktalmodus geschaltet hat?
Ja. Ich habe gerade das hier bei Firefox in die Konsole eingegeben:
parseInt("0213");und das hier bekommen:139Sag ich ja, solche Fehler treten nur in Nischenbrowsern auf. Wer nimmt denn schon noch Rücksicht auf den Firefox 😉
Wie schlecht, vor allem da Mozilla selbst noch darauf hinweist, dass dieses Verhalten falsch ist.
Nein, das hat nichts mit Nischenbrowser und Fehlverhalten zu tun. Mit parseInt kannst du in jedes Zahlensystem umwandeln. parseInt(’10‘, 8) wandelt in eine Oktale Zahl um. Ohne Radix wird normalerweise die 10 benutzt, ausser wenn im String eine Null vorne steht, das ist dann auch eine oktale Zahl. Eine Hexadezimale Zahl wäre 0x
alert(parseInt('0x15'));Deshlab bei parseInt() immer den zweiten Parameter benutzen.
Oh, und den letzten Absatz in der MDN Spezifikation kannte ich noch gar nicht.
Das ist ECMA 5, wo das nicht mehr der Fall ist. Das ist ganz aktuell und noch nicht alles wird von allen Browsern umgesetzt. ECMA 3 hat nichts mit IE 3 zu tun, falls ich deine Bemerkung oben richtig verstanden habe.
Das mit dem Nischenbrowser war Ironie.
Aber darum geht es ja: Man müsste eben nicht den zweiten Parameter verwenden, da der Standard vorsieht, dass auch parseInt(„08“) === 8 ist. Der zweite Parameter wäre demnach nur notwendig wenn man eine andere Basis als 10 verwenden möchte (was selten genug der Fall ist).
Leider halten sich einige Browser (wie offensichtlich der Firefox) nicht an den Standard; sie verhalten sich diesbezüglich falsch und interpretieren diese Zahlen als Oktalzahlen.
Mit IE meine ich den Internet Explorer. Und der IE 3 war irgend ein beliebiges Beispiel für einen sehr alten Browser.
Naja, das Verhalten zeigen eigentlich alle Browser, da es bis vor kurzem ja auch exakt so definiert war. Insofern bin ich von der Erwähnung des IE 3 etwas überrascht gewesen. Immerhin ist das der erste Browser gewesen der CSS konnte.
Das Verhalten zeigen nicht alle Browser (Chrome ist Gegenbeispiel) und „kurz“ ist ein relativer Begriff. Ich meine ja auch nur, dass es angenehm ist, dass der Standard das Problem nun doch recht eindeutig klärt.