Warum ist NumberFormatException ne RuntimeException?

Ne NumberFormatException tritt doch fast immer dann auf, wenn ein User einen Text anstatt ner Zahl eingegeben hat. Das sollte doch dann ne ganz normale Exception sein, wie z.B. FileNotFoundException. RuntimeExceptions sind doch mehr Programmierfehler also NullPointerException oder ArrayIndexOutOfBoundsException.

Ajaw

IOExceptions sind checked exceptions. Checked Exceptions treten da auf, wo Fehler nicht auf Fehler in der Programmlogik zurueckzufuehren sind, also z.B. Dateioperationen, Datenbankzugriffe, Netzwerkzugriffe,... Checked Exceptions muessen von dir als Programmierer gefangen werden.

RuntimeExceptions sind unchecked exceptions. Das sind Fehler in der Programmlogik. Sie werden von der JVM gefangen und sollten in der Regel nicht vom Programmierer gefangen, sondern beseitigt werden.

Eine NumberFormatException tritt ja nicht da auf wo der Benutzer eine falsche Eingabe macht, sondern wo du als Programmierer faelschlicherweise einen String in eine Zahl parsen willst. Also ist es eindeutig eine RuntimeException.

Ne FileNotFoundException tritt auf, wenn der Programmierer einen string als Dateinamen verwendet, obwohl es keine solche Datei gibt.

Warum soll ich den Prüfen, ob eine String wirklich ne Zahl ist, wenns beim parsen sowieso gemacht wird.

Javaner

bachstuben schrieb:

Warum soll ich den Prüfen, ob eine String wirklich ne Zahl ist, wenns beim parsen sowieso gemacht wird.

?

Ganz einfach damit du den User darauf hinweisen kannst,
daß er keine Zahlrepräsentation eingegeben hat.

Oder ich verstehe jetzt nicht, was du eigentlich meinst...

Ajaw

bachstuben schrieb:

Ne FileNotFoundException tritt auf, wenn der Programmierer einen string als Dateinamen verwendet, obwohl es keine solche Datei gibt.

Warum soll ich den Prüfen, ob eine String wirklich ne Zahl ist, wenns beim parsen sowieso gemacht wird.

Niemand zwingt dich dazu. Von mir aus kannst du das auch mit try und catch machen. Du musst es aber nicht. Und genau das ist doch der entscheidende Punkt.

Javaner schrieb:

bachstuben schrieb:

Warum soll ich den Prüfen, ob eine String wirklich ne Zahl ist, wenns beim parsen sowieso gemacht wird.

?

Ganz einfach damit du den User darauf hinweisen kannst,
daß er keine Zahlrepräsentation eingegeben hat.

Oder ich verstehe jetzt nicht, was du eigentlich meinst...

Ich meine, dass es ne checked Exception sein sollte, die man fangen muss und dann nen Fehler ausgibt.

Ajaw schrieb:

bachstuben schrieb:

Ne FileNotFoundException tritt auf, wenn der Programmierer einen string als Dateinamen verwendet, obwohl es keine solche Datei gibt.

Warum soll ich den Prüfen, ob eine String wirklich ne Zahl ist, wenns beim parsen sowieso gemacht wird.

Niemand zwingt dich dazu. Von mir aus kannst du das auch mit try und catch machen. Du musst es aber nicht. Und genau das ist doch der entscheidende Punkt.

Bei nem File kann ich auch so prüfen, ob es existiert, aber FileNotFoundException ist ne checked Exception die ich fangen muss, wenn die Datei nicht existiert, wieso ist NumberFormatException dann nicht checked? Nur weil sie von IllegalArgumentException Exception abgeleitet ist? Nen Dateinamen von ner Datei die nicht existiert könnte man dann auch als IllegalArgumentException betrachten.

Ajaw

Abermals: Wenn du einen String ungeprueft in eine Zahl parsen willst ist das ein Fehler in deiner Programmlogik. Wenn du einen Nullpointer an eine Funktion uebergibst ist das ebenso ein Fehler in deiner Programmlogik. Solche Bugs beeinflussen die Funktionalitaet des Programms und lassen sich groesstenteil nicht zur Laufzeit korrigieren, sondern du musst den Fehler im Quellcode korrigieren.

Wenn du dagegen eine FileNotFoundException wegen einer falschen Benutzereingabe kriegst beinflusst das die Funktionalitaet deines Programms nicht, wuerde aber Fehler verursachen, wenn du ohne sie zu fangen weiter machen wuerdest.

Du gehst immer von der Kombination Benutzereingabe->Parsen aus. Da waere eine checked Exception ja sogar noch sinnvoll. Aber so muss es ja nicht sein.

Gregor

Bei einer Datei können außerhalb des Programms Dinge geschehen, die dazu führen, dass eine Datei plötzlich nicht mehr aufgefunden werden kann. Das liegt also nicht völlig in der Kontrolle Deines Programms. Bei einem String kann man aber nachhaltig prüfen, ob er eine Zahl darstellt oder nicht. Da liegt es völlig in der Hand Deines Programms, ob Du den String als Zahl ansiehst oder nicht. Das heißt, dass Du jeden Fehler, der diesbezüglich auftreten kann, im Vorhinein vermeiden kannst. Wenn Du eine Datei laden willst, dann ist das nicht so.

EDIT: Abgesehen davon wird auch bei Strings, die zu Zahlen geparst werden sollen, oft ein try-catch verwendet. Aus dem einfachen Grund, dass die Java Standardbibliothek hier keinen Standardweg vorsieht, um zu überprüfen, ob ein String eine Zahl ist. Das müsste man also jedesmal selbst machen. Es gibt keine Methode "boolean DecimalFormat.isParsable(String s)". Das sollte man allerdings als einen Bruch der Prinzipien aus Pragmatismusgründen werten. Wenn das mit halbwegs vernünftigen Mitteln zu vermeiden ist, dann sollte man es auch vermeiden.

Gregor schrieb:

EDIT: Abgesehen davon wird auch bei Strings, die zu Zahlen geparst werden sollen, oft ein try-catch verwendet. Aus dem einfachen Grund, dass die Java Standardbibliothek hier keinen Standardweg vorsieht, um zu überprüfen, ob ein String eine Zahl ist. Das müsste man also jedesmal selbst machen. Es gibt keine Methode "boolean DecimalFormat.isParsable(String s)". Das sollte man allerdings als einen Bruch der Prinzipien aus Pragmatismusgründen werten. Wenn das mit halbwegs vernünftigen Mitteln zu vermeiden ist, dann sollte man es auch vermeiden.

Ja, nicht wirklich sauber, aber nen Regulärenausdruck für sowas, wäre wohl mit Kanonen auf Spatzen schießen.

Gregor

bachstuben schrieb:

Ja, nicht wirklich sauber, aber nen Regulärenausdruck für sowas, wäre wohl mit Kanonen auf Spatzen schießen.

Eigentlich wäre das völlig angebracht. ...IMHO.

Gregor schrieb:

bachstuben schrieb:

Ja, nicht wirklich sauber, aber nen Regulärenausdruck für sowas, wäre wohl mit Kanonen auf Spatzen schießen.

Eigentlich wäre das völlig angebracht. ...IMHO.

Wenn du dann mal nicht nur ein paar Zahlen hast, die der User eigegeben hat, sondern eine ganze Datei voll Zahlen, dann wird es um einiges langsamer.