On 18 July 2013 17:56, Mark Thomas <ma...@apache.org> wrote:
> sebb <seb...@gmail.com> wrote:
>
>>The MATH code base currently generates hundreds of boxing warnings.
>>Many, if not most, are perfectly OK.
>>For example, conversion of int and long to Number when throwing
>>various Exceptions.
>>
>>However, buried amongst the valid uses there may well be some code
>>that is buggy - e.g. it uses Long when it could use the primitive and
>>avoid the conversion overhead.
>>Or there is an unboxing conversion that fails to check if the field is
>>null.
>>
>>At present, there are just too many warnings for them to be any use.
>>
>>It occurs to me that it would be easy to add overloaded methods for
>>the Exceptions, for example
>>
>>NumberIsTooLargeException(Number, Number, boolean)
>>
>>could have the following overloads:
>>
>>NumberIsTooLargeException(int, int, boolean)
>>NumberIsTooLargeException(long, long, boolean)
>>NumberIsTooLargeException(float, float, boolean)
>>NumberIsTooLargeException(double, double, boolean)
>>
>>The int and float versions could probably be omitted without losing
>>essential information.
>>
>>Thoughts?
>
> From the peanut gallery that seems to be a perfectly reasonable approach to 
> reduce the warnings. If you add those methods (I'm guessing you are in a 
> position to do that pretty quickly) does it reduce the number of warnings to 
> a manageable level?

I'm hoping so, but did not want to start on something that was going
to be rejected.

There are currently 1705 boxing warnings (and about 300 unboxing)
This includes the test cases.

Adding public NumberIsTooLargeException([Localizable l.]long wrong,
long max, boolean boundIsAllowed)  and the double equivalents
reduces the number to 1577, i.e. 128 fewer. Still a way to go, but
there are quite a lot of these Exceptions.

> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to