Fehlerbehandlung beim Parsen von Strings

[kirdie]

Ich habe eine Methode, die aus einem String eine Instanz einer bestimmten Klasse erzeugt. Da ein Attribut der Klasse ein Doublewert ist, frage ich mich jetzt, wie ich eine NumberFormatException behandle.

P.S: Mensch ihr seid ja schnell mit dem Antworten, der Thread ist noch garnicht richtig fertig 🙂

Hier ein Beispielstring:

bla,blubb,0.5
bli,blo,0.7
blu,blarg,0.8

Das Format ist also String Komma String Komma Doublewert.
Allerdings soll ein Benutzer in einer GUI in einem Textfeld den String selbst erstellen und kann dabei ja auch Fehler machen.
Und die Klasse ist im wesentlichen eine Map<String,Map<String,Double>> mit ein paar Methoden.

P.S.: Habe in der API eine ParseException gefunden und jetzt erstmal folgenden Code. Ist das ok so?

...
try{mapping.add(tokens[0], tokens[1], Double.valueOf(tokens[2]));}
catch(NumberFormatException e) {throw new ParseException("Error parsing line "+line, lineCount);}
...

 

[eRaaaa]

Wie ist denn der String aufgebaut(z.b. komma getrennt? json? 😀) ? Weisst du nicht dass sich an dieser Stelle ein doublewert kommt? :bahnhof:

/edit: mir fehlt da eine entscheidende antwortmöglichkeit. und die hat nichts mit einer exception zu tun - würde vorher schon zusehen dass es erst gar nicht zu solch einer kommen kann...

 

[ARadauer]

Das ist eine fachliche Entscheidung... und kommt drauf an...
Aber im generell wenn der Benutzer es eingibt, würde ich ihm direkt einen Fehler anzeigen...

 

[Marco13]

würde vorher schon zusehen dass es erst gar nicht zu solch einer kommen kann...

Es gibt keine wirklich praktikable Möglichkeit, bei einem beliebigen (ggf. vom Benutzer eingegebenen) String zu erkennen, ob es ein gültiger double-Wert ist, außer zu parsen und (durch Fangen der Exception) zu schauen, ob es geklappt hat.

Eigene Exception-Klassen sollte man sparsam einsetzen. Die ParseException wäre eine Option. Da man keine "cause"-Exception übergeben kann, sollte der Message-String aber vielsagender sein. Aber... auch die ParseException wird man doch irgendwo abfangen und dem Benutzer einen Hinweis präsentieren? (Ggf. den Text des Eingabefeldes Rot machen und eine Statusmeldung, oder den schon Erwähnten Dialog...)

 

[eRaaaa]

Es gibt keine wirklich praktikable Möglichkeit, bei einem beliebigen (ggf. vom Benutzer eingegebenen) String zu erkennen, ob es ein gültiger double-Wert ist, außer zu parsen und (durch Fangen der Exception) zu schauen, ob es geklappt hat.

Wie der String aussieht und dass der in einer GUI vom User eingegeben werden kann war bis zu dem Zeitpunkt als ich den Post machte noch gar nicht klar 🙂

Aber auch dafür könnte man evtl. den Scanner benutzen, da kann man sogar locale spezifisch was abfragen in Sachen hasNextDouble.... :bahnhof:

 

[Spacerat]

ParsingImpossibleException? Was das denn? Das Parsen selbst dürfte kaum unmöglich sein sondern eher der Umstand nach einer Fehleingabe brauchbare Ergebnisse zu liefen. Also wenn es 'ne Exception sein soll, dann NumberFormatException. Aber wieso überhaupt eine mögliche Exception einplanen, wenn es andere Möglichkeiten gibt, Zahlen sicher zu erkennen. Je nach Quelle der Daten bieten sich diverse Methoden an. Zum einen RegEx - hat den Vorteil, dass die Datenquelle relativ egal sein darf, aber den Nachteil, dass man sich möglicherweise mit etwas Neuem auseinander setzen darf, was einem immer wie ein rotes Tuch vorkommt. Zum anderen der StreamTokenizer - Der Vorteil bei diesem ist, dass standardmässig dazu in der Lage ist, Texte aus einem Stream zu lesen und dabei auch direkt Zahlen (doubles) erkennt. Der Nachteil: Er lässt sich nur auf Streams (also Dateien oder ähnlichem) anwenden.

 

[Marco13]

Also wenn es 'ne Exception sein soll, dann NumberFormatException.

Ich nehme an, das war einer der Punkte, die ARadauer mit "Das ist eine fachliche Entscheidung" meinte (und die ohne genaueres Wissen über den Kontext schwer enscheiden werden können) : FALLS dort z.B. auch der Fall auftreten kann, dass man ein Datum parsen muss, dann wäre eine NumberFormatException unpassend, und es könnte sinnvoller sein, "alle parsing-Exceptions" in eine allgemeine "ParsingException" oder so einzuwickeln...

Aber wieso überhaupt eine mögliche Exception einplanen, wenn es andere Möglichkeiten gibt, Zahlen sicher zu erkennen. Je nach Quelle der Daten bieten sich diverse Methoden an. Zum einen RegEx - hat den Vorteil, dass die Datenquelle relativ egal sein darf, aber den Nachteil, dass man sich möglicherweise mit etwas Neuem auseinander setzen darf, was einem immer wie ein rotes Tuch vorkommt.

Ich hatte schon ein paar mal die "Challenge" gestellt: Jemand soll eine RegEx definieren, die GENAU die Strings matcht, die mit Float.parseFloat fehlerfrei zu einem float geparst werden können. Bisher hat sich noch keiner getraut... Willst du mal dein Glück versuchen? 😉

 

[Spacerat]

@Marco13: Wie genau meinst du das? Was macht [c](\\d+)[/c]? Reicht das nicht? Bin da wirklich nicht all zu firm.

 

[Marco13]

Das 'd' erkennt Ziffern. Schon ein "-1" würde nicht erkannt. Ein "-1.2" sowieso nicht. Bei sowas wie "-.1e2f" haut's wohl auch ausgefeiltere RegExes raus. Und wenn jemand meinen würde, alles abgedeckt zu haben, würde ich eines meiner Asse ausspielen, und ihm klarmachen, dass er "NaN" vergessen hat 😀

 

[kirdie]

Vielen Dank für die vielen und schnellen Antworten. Ich habe mich aber entschieden, bei der ParseException zu bleiben, da diese den Vorteil hat, dass sie die Zeilennummer enthält. Dadurch kann ich dem Benutzer die entscheidende Zeile dann rot markieren und er kann sie korrigieren. Reguläre Ausdrücke kann ich aber ich finde sie hier nicht so passend.