On 9/12/12 8:52 AM, Gilles Sadowski wrote: >> [...] >> >> 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"!
I am only referring to APIs that explicitly disallow nulls. I have agreed that we will not always do this. The specific case being discussed here is an API that is going to include as an explicit precondition that nulls are not allowed. When this is done, what should be thrown is an IllegalArgumentException, which for us means some subclass of MathIllegalArgumentException. > > If we sometimes check and sometimes not, the thrown exception will be from a > different hierarchy (NPE vs MathRuntimeException). This is annoying (and > inconsistent). That is an unfortunate consequence of not always checking. I understand that it may be impractical to always check. Therefore, some NPEs are going to be propagated to clients with no warning. > > 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. And inferior first failure data capture and potential additional computation, side effects or other unknown consequences (unless we always think through the consequences of nulls propagated through our code and make sure there are never any untoward side effects. All of these are reasons for the "when you must fail, fail fast and loudly" maxim. I understand that it may not be possible to adhere to this fully in [math]. > 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).] The latter is a good point and why I am OK not checking everywhere. > >> 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. Here you are missing the point above - we are talking about specific APIs that explicitly disallow nulls. Just as we trap or check arguments to avoid array index errors, we can in some cases do the same for nulls. In these cases, it is appropriate to throw IAE for the nulls just as we do for the (avoided) AIOBE. > > 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. I am not. I have agreed that we can go back to a common root. But that then forces us to create surrogates for the top level exceptions such as IAE that the "math" versions used to subclass. I am OK with that. But we should maintain the semantics correctly, throwing a MIAE when API contracts are violated. > >> [...] 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
