> [...]
>
> I know this is a little of a sore subject, but in this and other
> cases where arguments violate documented preconditions, I think we
> should throw IAE, which means MNAE is only appropriate as long as it
> continues to subclass our surrogate for IAE - MIAE.
>
> If I sound hard-headed here, it would be great if someone could
> explain to me what is different about null arguments at the point of
> method activation in an API that explicitly disallows them.
> Consider, e.g. an empty array or array indices that will lead to
> index out of bounds errors in APIs that take arrays. What is so
> different about null? All are bad arguments violating API contract,
> all detected at method activation time -> IAE.
Okay, I'm going to lay out again the arguments (all which I know about were
already mentioned in the thread).
[I'll try to demonstrate that where we differ is on the usefulness of having
a policy!]
Taking quotes from your mail in reversed order:
> All are bad arguments violating API contract,
> all detected at method activation time -> IAE.
Agreed... if the policy is to _always_ check for "null"!
If we sometimes check and sometimes not, the thrown exception will be from a
different hierarchy (NPE vs MathRuntimeException). This is annoying (and
inconsistent).
The oft-repeated issue is "Is it useful to check for null or not?"; at least
4 people answered "No", because this bug will never go unnoticed: sooner or
later, using "null" _will_ raise exception. The sole and unique difference
with CM checking and JVM checking is that the stack trace will (sometimes)
be a little shorter in the former case. Most people have come to agree that
it's not worth adopting a policy of thorough checking. [Rationale 1: users
who encounter a NPE will need to inspect the stack trace and go to _their_
code in order to see where _they_ put a "null". Rationale 2: there is
probably a performance penalty to all these checks (especially in a well
tested code where "null" reference bugs have been ironed out).]
> Consider, e.g. an empty array or array indices that will lead to
> index out of bounds errors in APIs that take arrays. What is so
> different about null?
There is no difference... if there is a policy that decrees so.
It is _not_ the policy of the JDK: "NullPointerException" is not the same
error as "IndexOutOfBoundsException"; their common parent class is the
(unspecific) "RuntimeException" and their sibling is
"IllegalArgumentException".
There is no "is-a" relationship between NPE, IOBE and IAE.
Recalling that some 1.5 years ago you were against the adoption of the
single exception hierarchy, rooted at "MathRuntimeException", in order to
stay faithful to the JDK exception types, I wonder why you are on the
opposite stand as NPE is concerned.
> [...] what is different about null arguments at the point of
> method activation in an API that explicitly disallows them.
The difference is that there is no need to tell the user what the problem
is because the raised exception says it all: "You tried to use a null
reference." [As said above, the only issue is _when_ the exception is
triggered.]
The policy mandates what is globally valid, e.g.:
"If not specified otherwise, "null" is not allowed as an argument."
Then, a user cannot complain about a NPE being propagated when he passed an
invalid (null) argument.
Finally, the case for "null" is also slightly peculiar (given the above)
that it should not simply be bundled with the rationale "Fail early": Indeed
"null" references always fail early (i.e. as soon as they are used).
Deferring the check until it is done by the JVM will never entails the code
to produce a wrong result _because_ of that null reference (it will just
fail in the predictable way: NPE).[1]
Gilles
[1] Unlike in C, where an unitialized pointer would not necessarily crash
the program, but _could_ make it behave erratically (including produce
wrong results in a stealth way).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
