commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-856) Deprecate "NullArgumentException"
Date Sat, 08 Sep 2012 09:43:07 GMT

    [ 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

Mime
View raw message