[threeten-dev] [threeten-develop] Review for minor update to ValueRange checkValidIntValue

[roger riggs]

Hi,

Makes sense.

I inlined the equivalent of checkValidIntValue in TemporalAccessor.get.
The @throws clauses were slightly out of alignment with 
TemporalAccessor.get.
To make it simplier to maintain the implementers now use {@inheritDoc}.
The ValueRange.checkValidIntValue exception message is updated to more 
informative.

Updated webrev:

Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-checkvalid-274/

Thanks, Roger

On 3/5/2013 8:49 AM, Stephen Colebourne wrote:
> I don't think this change can go in.
>
> The checkValidValue methods are public, and so can be called by anyone
> at any time in any way. The UTTE is intended for use when the Field or
> Unit passed in is unsupported by the target object. In these methods,
> the field is optional, and supported/not-supported is not a quality of
> the ValueRange class. Thus UTTE is just plain wrong to be thrown here.
>
> A correct fix would be to inline the code change into TemporalAccesor
> and anywhere else that has a similar use of the check method. If it is
> widely used, a package scoped method (in an appropriate location) may
> be a solution.
>
> thanks
> Stephen
>
>
>
> On 4 March 2013 17:53, roger riggs <roger.riggs at oracle.com> wrote:
>> Hi,
>>
>> A simple fix for the exception and message when TemporalAccessor.get()
>> is used (incorrectly) to retrieve Fields with long values.
>>
>> Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-checkvalid-274/
>>
>> Thanks, Roger
>>
>>