Le 04/08/2010 15:28, Gilles Sadowski a écrit :
>>>> Why not in the new "exception" package?
>>>> [The aim being to deprecate the old "MathRuntimeException".]
>>>
>>> Sorry for that. I'm still not used to the new package.
>>> Could you look at the various createXxxException factory methods in and
>>> replace them by dedicated exceptions in the new package ? Obviously this
>>> one is used only from one class but the older ones are more heavily used.
>>
>> I've created "MathUnsupportedOperationException" (not committed yet). I was
>> going to create "MathNullPointerException" but then looking at the usage in
>> CM, I noticed that most checks for "null" result in throwing an
>> "IllegalArgumentException"; exceptions to that rule appear in class
>> "BigFraction". The usage should be consistent. I think that it is fine to
>> use "MathIllegalArgumentException" everywhere. In which case I think that
>> that we shouldn't have a "MathNullPointerException" at all (and never throw
>> a "NullPointerException" explicitly from CM, so that when it happens, it
>> will mean that some check is missing somewhere).
>
> 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.
> 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.
Luc
>
>
> 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
