Re: [threeten-develop] DateTime supported fields

[roger r. <rog...@or...>]

On 7/25/2012 11:49 AM, Stephen Colebourne wrote:
> On 25 July 2012 15:49, roger riggs<rog...@or...>  wrote:
>> Note that applications should hopefully be able to write code to check
>> whether the exception will occur or not;
>>    if ( field.isSupported(time) ) {
>>      time.get(field)
>>    }
>>
>> I would not support adding this to the API, because it does not just add
>> it to
>> fields but the operation would need to be delegated to the DateTime and
>> adding an isSupported method to DateTime.
The original example was on the DateTimeAdjuster API using plus().
In that case, throwing a CalendricalException is preferred, though 
returning null might
be a close second.  Return null is more likely to lead to NPE's.

And that's preferable in DateTime.with() as well.

> This method was on the API for many years and was removed during the
> recent changes. It is not acceptable to developers to have to "try and
> hope" by catching an exception given a DateTime instance. It has also
> been a goal of the JSR to avoid users being required to catch
> exceptions to achieve functionality, and for no significant exceptions
> to be caught in the 310 implementation itself (see
> DateTimePrintContext:197 for an example where that isn't true today).
>
> The main options are
> 1) only have get() returning long and force users to catch exceptions
> ("try and hope")
> 2) only have get(), but it returns Long and must be checked for null
> ("try and NPE")
> 3) have two methods, an extract() returning Long and a get() returning int
> 4) have two separate methods get() and isSupported()
Equally bad is requiring two method calls for every one,  isSupported() 
before every get().

In our discussions in London about the builder I though we avoided this
situation by exposing the list of supported fields then the caller could in
bulk know what fields were available.

Lets get the rest of the EDR out and come back to the builder after the
EDR.  It has more issues than just this.

Roger


>
> I believe that "try and NPE" is a recipe for NPEs (most don't bother
> to check), while "try and hope" is horrible for usability in client
> code. Option 3 basically tries to artificially invent a use case to
> have two methods, neither of which perform exactly as desired. JSR-310
> has tried all four over time, and option 4 is in my view by far the
> nicest.
>
> See explore/issupported branch for one implementation option which
> uses extract(Class) to avoid extra methods. I think that replicating
> the get/with doGet/doSet design may be cleaner and faster, however
> that couldn't handle the "preferred" field set of this approach.
>
> The same isSupported() issue applies to PeriodUnits and will also need
> to be solved.
>
> This is necessary to implement builders properly. A LocalDate builder
> must try a number of different combinations of date-time fields in
> order to form a date. Without the ability to check isSupported() this
> requires catching lots of exceptions, which is not acceptable.
>
> Stephen
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> threeten-develop mailing list
> thr...@li...
> https://lists.sourceforge.net/lists/listinfo/threeten-develop

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment