java amateur
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
java amateur
java amateur
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
java amateur
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
java amateur
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
java amateur
42
Just make sure you aren't using that code from multiple threads. DateFormat and its subclasses are not threadsafe.Originally posted by Jeroen Wenting:
ddf is a static DateFormat constructed using the default formatting string for our application.
java amateur
God Gave Me Nothing I Wanted<br />He Gave Me Everything I Needed<br /> - Swami Vivekananda
Anyway, the reason you were getting the exception is that DateFormat chose a default format based on your default locale which put the month before the day of the month. While using your own date format is definitely the easiest route, there shuold be a way to set your locale to one that uses day of month first if you care to dig a little deeper. Take a look at the java.util.Locale class.
java amateur
That should beHowever, looking at the JavaDocs for Locale I only see NumberFormat mentioned -- not DateFormat.Originally posted by miguel lisboa:
Locale l = new Locale("pt, pt");
Regardless, if you fix the cause of the ParseException, you still have to catch or declare it in your throws clause. The catch/throw declaration is enforced by the compiler since ParseException is a checked exception.
java amateur
I say go (re)read the JavaDocs for SimpleDateFormat.parse(String, ParsePosition). If it fails to parse, the position isn't updated, its error index is set, and null is returned. Thus you're deciding betweenandI vastly prefer using try-catch to handle error flows as the code in the try-block can proceed without regard to checking for errors. Having if-tests throughout your code checking for error conditions breaks up the flow, making it harder to read.Originally posted by miguel lisboa:
in order to avoid one line of code
i've to write much more, i guess i should stay with my original aproach. What do you say?