[
https://issues.apache.org/jira/browse/MATH-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451292#comment-13451292
]
Gilles commented on MATH-856:
-----------------------------
bq. I do not want to reduce robustness in places where we document null
handling and throw IAE with informative messages where not allowed nulls are
provided.
The issue which we started to discuss on the ML is whether checking for "null"
is useful or not.
The majority seems to agree that it is not.
The code will _not_ be less robust without CM checking for null, since such
bugs will raise a NPE generated by the JVM.
bq. Propagating runtime exceptions with no warning is a bad practice [...]
I don't understand what you mean by "no warning". Everybody knows that Java
will raise a NPE when a null reference is used.
The point is indeed that _we_ don't propagate (unless there is a bug in CM
where _we_ created and subsequently used a null reference).
bq. [...] developers do not want to add null checking everywhere [...]
That's the crux of the issue. Doing so is duplicating the JVM check with no
added value: the information is not more detailed; it is just the same ("a null
reference was used").
The sole difference is that the exception might be raised one or two levels up
the stack.
This gain (of dubious usefulness) must be balanced with the (even slight)
performance loss incurred by checking for null everywhere.
bq. A null array, an empty array, a bad set of indices are all the same in most
places in the stats package - all violate the fully specified API contract and
lead to informative IAEs.
I never proposed to drop checks for
* empty array
* bad set of indices
In those cases, the reason for the error cannot be inferred from just _raising_
an exception; there is undoubtedly an added value to a more specific exception,
with a more detailed message (if needed) and, possibly, additional information
stored in the "ExceptionContext".
Just raising NPE _is_ enough to convey the reason with full meaning disclosure:
a null reference was used.
bq. The NAE is needless, [...]
The statement is in contradiction with the usage you want to maintain.
NAE exists to encapsulate the localizable error message
("LocalizedFormats.NULL_NOT_ALLOWED").
bq. If we can't agree to drop it but replace with MathIAE, [...]
NAE inherits form MathIAE, thus it *is* a MathIAE, it can be used as a MathIAE,
and it is more useful than MathIAE (for developers and users alike). There
isn't a single advantage to using MathIAE over NAE.
If some null checks remain and must be reported, why would you want to delete
this class, which does the same job as MathIAE but more concisely?
> Deprecate "NullArgumentException"
> ---------------------------------
>
> Key: MATH-856
> URL: https://issues.apache.org/jira/browse/MATH-856
> Project: Commons Math
> Issue Type: Task
> Affects Versions: 3.0
> Reporter: Gilles
> Priority: Trivial
> Fix For: 3.1, 4.0
>
>
> [Discussions|http://markmail.org/message/cl2e6c4pqbluo63e] on the "dev" ML
> concluded that "NullArgumentException" was more of a burden to maintain than
> it brings benefits.
> It will be deprecated in 3.1 and removed in 4.0.
> Checks for "null" in CM code will either be maintained or be removed.
> Whenever checks for "null" are performed, the exception to be thrown is the
> standard "NullPointerException" (instantiated with the no-arg constructor).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
