Validierung einer Zeichenkette für SimpleDateFormat

[ladida]

Hallo,

gibt es eine einfache Möglichkeit zu überprüfen ob eine dem SimpleDateFormat übergebene Zeichenkette auch valide ist?

Bsp:

DateFormat df = new SimpleDateFormat("yyyy-M6M-dd hh:mm:ss,SSS");

Die '6' zwischen den beiden M's ist ja dort eigentlich fehl am Platz. Und wenn ich dann

Date d = df.parse("2013-01-16 05:40:09,616");

aufrufe, kracht es natürlich.

Ich weiß ja nicht ob es eine sinnvolle Anwendung gibt, die zB eine Ziffer zwischen dem Buchstaben benötigt. Aber irgendwie kann ich es mir nicht vorstellen. Daher müsste es ja eine Möglichkeit geben zu überprüfen ob mein Dateformat brauchbar ist oder im Grunde nie zu einer Konvertierung führen kann.

Danke im voraus.

 

[nillehammer]

Wenn der angegebene Formatstring überhaupt nicht zu einer Konvertierung führen kann, dann schmeißt der Konstruktor des SimpleDateFormat selbst eine IllegalArgumentException. Darüber hinaus ist das SimpleDateFormat sehr großzügig. Das ist vonden Entwicklern wohl bewusst gemacht worden, um es möglichst vielseitig einsetzbar zu halten. Du kannst für Dich selbst natürlich striktere Kriterien definieren und diese selbst vorher überprüfen.

 

[Gast2]

du kannst den Aufruf einfach in einen try-catch-Block packen und die Falscheingabe abfangen

 

[SlaterB]

@nillehammer
wie man sieht wird M6M durchgelassen, IllegalArgumentException kann überhaupt nur bei Buchstaben != GyMdkHmsSEDFwWahKzZ kommen

M6M kann durchaus noch arbeitsfähig sein, etwa für die format()-Methode, aber parse() ist anscheinend nicht zum Arbeiten zu bewegen,
darauf gibt es soweit ich weiß keinen vorherigen Test, wirklich eine gewisse Zwickmühle

@jurom
es geht um falsches Pattern, nicht falsches Datum

hatte ich anfangs auch so verstanden, mein Text dazu nicht mehr wirklich passend, aber zu schade zum Wegwerfen :

--
wenn es beim Parsen kracht dann ist das doch ein guter Check, mache das so früh wie nötig, fange die Exception ab

allgemein ist es sicherlich nicht so schön, mit Exceptions zu arbeiten,
ein catch auf NullPointerException, wo ein if (x == null) genauso ginge, verbietet sich,
genauso etwa File.exists() statt FileNotFoundException

bei komplizierten Parsen gibt es aber andere Prioritäten, da wäre es ein Frevel, eine Prüf-Methode anzubieten, falls diese dann intern die hunderte Zeilen an Parse-Code genauso implementieren müsste (wie sonst testen?), nur um an jeder Stelle womöglich mit boolean false abzubrechen,

maximal könnte man auf eine fertige Methode hoffen, die das Parsen ausführt mit try/catch drumherum,
das gibt es hier womöglich nicht, dann musst du das eben machen, gleich richtig auch mit Methode, nicht mehrfach
denselben try/catch-Code im Programm
--

 

[ladida]

Ja, dachte mir schon das die meisten denken das ich Probleme mit dem Parser an sich habe.

Wenn ich erst beim parsen prüfe, erfahre ich aus der Meldung nicht wirklich aus welchem Grund die Exception geworfen wurde, da es ja auch sein kann das das Muster korrekt ist nur der Datum anders aufgebaut ist. Und ich wollte das möglichst zeitig prüfen. Naja, dann wird das wohl eine kleine riskante Stelle meines Progs werden. ^^ Müssen die Leute halt aufpassen was sie für ein Muster eingeben.

Danke euch erstma,
ladida

 

[freez]

Müssen die Leute halt aufpassen was sie für ein Muster eingeben.

Was hältst du davon, den "Leuten" ein Set von Pattern vorzugeben. Auf Anfragen kannst du es um weitere Pattern ergänzen. Somit würde es wenigstens nicht so aussehen, dass dein Programm falsch funktioniert, weil der Fehler an anderer Stelle kommt.

Alternativ kannst du die Patterneingabe grob auf Konsistenz prüfen und dem User eine Meldung ausgeben, dass dieses Pattern vermutlich nicht funktioniert. Vermutlich wirst du nicht jede Falscheingabe so abfangen können, aber sicherlich die meisten.

 

[ladida]

Da es aus einer xml-Datei eingelesen wird, ist das mit dem Set von Pattern auch nicht die erste Wahl. Desweiteren weiß ich nicht auf welche verrückte Weise das Datum irgendwann mal formatiert ist.

"grob auf Konsistenz" hat ich auch schon im Kopf, nur habs verworfen, ich hoffte irgendwas zu finden was einfach ist und möglichst alles abdeckt.

Naja, im Grunde werden eh nur Java Entwickler diese Formatvorlage ändern, die sollten wissen was geht und was nicht. Wäre nur ein "nice to have" feature gewesen.

Aber danke euch

 

[SlaterB]

> "grob auf Konsistenz" hat ich auch schon im Kopf, nur habs verworfen, ich hoffte irgendwas zu finden was einfach ist und möglichst alles abdeckt.

was spricht dagegen, solange zumindest die simplen Fälle abzudenken, die anscheinend auffallen, irgendwie musst du ja auf M6M gekommen sein

- Buchstaben != GyMdkHmsSEDFwWahKzZ macht wie gesagt der Konstruktor von SimpleDateFormat,

- alle Nicht-Buchstaben/ Nicht-Zahlen dürften als Zeichen an sich unproblematisch sein,
merkwürdig ist dann aber evt. noch sowas wie "M:M", also innerhalb eines Auswertblocks,

das funktioniert zwar in einem Beispiel ohne Fehlermeldung, aber sinnvoll zulassen kannst du das doch wohl nicht,
oder gestaltest du das Programm so offen, dass vielleicht der Anwender doch irgendwas im Sinn haben könnte, auch wenn du es nicht weißt?
jedenfalls wäre es dazu möglich zu prüfen, dass kein Buchstaben-Abschnitt doppelt vorkommen darf, kein M und später abgetrennt wieder ein M,
dafür kann man entsprechenden Code finden, wenn man sich für diese Regel entscheidet (empfehle ich im Moment)

edit: und schon ist der Moment wieder vorbei:
während "M:M" z.B. "1:1" nicht als November erkennt, kann "yy:yy" "19:85" oder auch "20:01" korrekt parsen,
ist zwar weiter relativ komisch, aber theoretisch denkbar


- zu Zahlen: alleinstehend anscheinend kein Problem, "MM 6" geht, als Trenner evtl. sowieso schon erkannt,
ansonsten gilt zumindest für Zahlen recht deutlich: keine Zahl in direkter Nachbarschaft von Buchstaben zulassen,
"M6M" ist schlecht, "MM6" aber auch, während etwa "MM:" kein Problem ist

auch das kann man als Regel formulieren, mit Code prüfen, mach es und filtere so einige Falschpattern raus, oder lasse es sein,
darauf zu verzichten nur weil keine fertige Methode zu finden ist, scheint mir nicht ganz logisch,

das Risiko, richtige Pattern auszusortierten, wäre schon eher ein Punkt,
ob es beherrschbar ist/ es wert ist, musst du natürlich selber entscheiden

 

[ladida]

"musst du natürlich selber entscheiden"

Hab entschieden das es, da mir keine Standard Methode bekannt ist, keine weitere Zeit darin investiere. Es gibt noch so viele andere Probleme zu lösen.

PS: Die Entscheidung ob ein Thema als Geschlossen gilt solltest du dem Ersteller überlassen. Vielleicht kommt ja irgendwann jemand und kennt zufällig die passende Standard Methode in dem riesigen Java Packet.

 

[SlaterB]

> Die Entscheidung ob ein Thema als Geschlossen gilt solltest du dem Ersteller überlassen.

in diesem Fall mag ich dies deiner Verantwortung überlassen, aber die Gedanken dazu:
- 90% aller neuen User übersehen das
- achte auf die Formulierung, 'Aber danke euch' klingt eher nach Themenende, als offene weitere Betrachtung

- 'Vielleicht kommt ja irgendwann jemand': was nach einen Tag in den Archiven steht, findet kaum mehr jemand,
vielleicht über Suche, aber nicht normale Durchsicht, der Erledigt-Status ist dann egal,

aber aktuell gehen viele Gäste die Themen der ersten Seiten durch, womöglich schauen viele umsonst hier rein, obwohl praktisch nichts mehr zu sagen ist, das Thema ist aktuell zu Ende, abgesehen wirklich von dem Strohhalm, dass jemand eine solche Methode kennt

 

[ladida]

'Aber danke euch' nennt man Höflichkeitsfloskel. Mögen einige. Warum auch immer.

Der Strohhalm das Hansa Meister wird ist auch nicht dicker. Aber lassen wir das lieber...