RFR 9: 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked exception
Roger Riggs
Roger.Riggs at Oracle.com
Mon Mar 14 20:17:13 UTC 2016
Hi Stephen,
Thanks for the comments and suggestions.
I have no issue cleaning it all up in one change.
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-format-8085887/
On 3/12/2016 4:47 AM, Stephen Colebourne wrote:
> I think the new text needs should be more specific:
>
> The {@code FULL} and {@code LONG} styles typically require a time-zone.
> When formatting using these styles, a {@code ZoneId} must be available,
> either by using {@code ZonedDateTime} or {@link DateTimeFormatter#withZone}.
ok
>
> (testing shows that the other two styles appear to not use the time-zone.)
>
> While it would be nice to support these styles when no time-zone is
> available, that seems like an unrealistic goal.
>
>
> Beyond this, the error message is terrible, eg:
> Unable to extract value: class java.time.format.DateTimePrintContext$1
> Unable to extract value: class java.time.LocalDateTime
> Unable to extract value: class java.time.OffsetDateTime
>
> This requires two separate changes.
> 1) Add toString() to the inner class at line 185 in DateTimePrintContext
Delegates to the temporal.
>
> 2) At line 282 in DateTimePrintContext, the exception message needs to
> record what is being queried - ZoneId, ZoneOffset, Chronology etc.
> Something like:
> if (query == TemporalQueries.zoneId() {
> throw new DateTimeException("Unable to extract ZoneId from temporal:
> " + temporal.getClass());
> } else if (query == TemporalQueries.zoneOffset() {
> throw new DateTimeException("Unable to extract ZoneOffset from
> temporal: " + temporal.getClass());
> } else ...
An more general alternative would be to add toString methods to each of
the TemporalQuery instances
but that would mean giving up the use of lambda for their implementations.
Thanks, Roger
>
> I'm happy for the error message problem to be fixed in a different
> issue if desired.
>
> Stephen
>
>
>
> On 11 March 2016 at 20:19, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Please review java.time javadoc improvements to highlight a common
>> misunderstanding
>> about formatting elements that require a timezone in addition to the time.
>> When using locale specific formatting, it may work if the locale formatting
>> does not
>> require a timezone or fail if the locale formatting requires a timezone and
>> a timezone is not provided.
>>
>> ZoneDateTime or OffsetDateTime types should be used when formatting with
>> locale
>> dependent formatters.
>>
>> 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked
>> exception
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-format-8085887/
>>
>> Thanks, Roger
>>
More information about the core-libs-dev
mailing list