Gilles Sadowski wrote:
>>> A simpler policy would be to not check for "null" and let the JVM do it. As
>>> the JVM will do it anyway, it's a redundant check when the reference is not
>>> null, i.e. most of time (in legitimate usage).
>> This simpler policy seems fine to me.
>> However, it is an important change from previous behaviour.
Sorry, I am not sure I understand what you mean by the "simpler
policy." Which one do you mean:
0) remove null checks uniformly and just let NPEs propagate everywhere
1) remove NPE wrappers, propagating uwrapped NPEs where the code
wraps and rethrows NPE today.
2) other?
I am -1 on 0), since this would result in loss of FFC info available
in the cases where we rethrow NPE as IAE with an exception message
indicating which argument was null (like the examples below).
If what you mean is 1), I am OK with the change; but we should make
the changes in the 3.0 branch as this could break apps that catch
the wrapped exception (unless I am missing something).
Phil
>
> In practice it is not that important: there are currently only 29
> occurrences of messages referring to "null"; among those only 6 raise a
> NullPointerException (the others throw an IllegalArgumentException).
>
>>> When the usage is wrong, the error is obvious and always the same ("null
>>> reference") and the "NullPointerException" fully identify the problem. I
>>> don't see why we should have a localized version of it. Yes, again, there
>>> are detailed messages saying:
>>> "the covariance matrix cannot be null"
>>> "the function cannot be null"
>>> "the denominator cannot be null"
>>> etc.
>>> But since any reference can potentially be "null", do you really intend to
>>> have a specific meesage for every object?
>> For these very low level errors, I would be happy with the single
>> message from JVM.
>
> So, shall I remove all checks for "null" (and those items in
> "LocalizedFormats" that are used for reporting it)?
> Should I open a JIRA issue?
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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
