RE: [Subclipse-users] Number Format Exception with show history
From: Stephen Elsemore <selsemore_at_collab.net>
Date: Fri, 26 Apr 2013 15:30:14 +0000
Scattered thoughts on this:
According to the javadoc, SimpleDateFormat.parse throws only ParseException, but as the stacktrace shows it is throwing NumberFormatException in this case. So, in a sense, this is problem at the Java level. But it could probably be handled at the JavaHL level.
org.apache.subversion.javahl.types.LogDate takes a date String in the constructor and tries to parse it into a Date. But, before doing that, it does a basic preliminary check to see if the date String is validly formatted:
if (datestr == null || datestr.length() != 27 || datestr.charAt(26) != 'Z')
Apparently this check passes, since a ParseException is not thrown. Although it's possible that the date String is still not properly formatted, it seems unlikely. This makes me suspect that this could be a threading issue. There are all kinds of warnings about SimpleDateFormat not being thread safe, and that a single SimpleDateFormat instance should not be used by multiple threads without proper synchronization. But this is what LogDate does:
private static final DateFormat formatter = new SimpleDateFormat(
And in constructor:
Date date = formatter.parse(datestr.substring(0, 23) + " UTC");
I'm not sure offhand if/when/where Subclipse might get log messages from multiple threads, but it's certainly reasonable that Subclipse or some other consumer might do this, so LogDate should be thread safe. Maybe something like this:
Date date;
Probably it wouldn't hurt to throw a try/catch around the parse as well, in case for whatever reason the date String is truly formatted incorrectly.
The org.tigris.subversion.svnclientadapter.javahl.JhlLogMessage constructor does wrap the LogDate creation with a try/catch:
try {
Since nothing is being done with the exception anyway, it probably wouldn't hurt to catch Exception rather than ParseException to prevent unexpected errors (like NumberFormatException) from going any further (this fix can be made at the Subclipse level). This would result in logDate being null, but JhlLogMessage.getDate() looks like this:
public Date getDate() {
Which means that a date that was actually formatted incorrectly would ultimately show up in the history view and other places that show log dates as something like "12/31/69 4:00pm", rather than "Not Available" (which is what the history view will show if an actual null date is returned. This isn't ideal, but I'd be reluctant to change the getDate() method because it would take some effort to determine if all callers properly handle a null date being returned (probably not, since this code was written this way in the first place).
> -----Original Message-----
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
|
This is an archived mail posted to the Subclipse Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.