Hi Phil >> >> Back to square one, with 3 fully consistent alternatives: >> 1. CM to always check for null? Then "NullArgumentException" inheriting from >> "MathIllegalArgumentException" is fine because we promise to the user >> that >> no NPE will ever propagate through the CM layer. [Breaking that promise >> is a CM bug.] >> 2. CM to never check for null? Then we delete class "NullArgumentException". >> Users are warned by the general policy: "Do not pass null unless it is >> explicitly documented to be allowed." A bug will lead to the JVM raising >> a NPE. >> 3. CM to sometimes check for null? Then "NullArgumentException" should >> inherit from "NullPointerException" because the user will sometimes see >> "NullArgumentException" (when CM checks) and sometimes NPE (when CM does >> not check) and both should thus belong to the same hierarchy (from the >> user's point-of-view, there is no reason to handle them in different >> ways since it's the exact same bug). >> For the user, the consequence will be similar to alternative 2, with >> sometimes more information about the failure and sometimes (marginally) >> earlier detection. > > As stated above, my preference is > > 4. CM APIs *may* disallow nulls explicitly. When that is done, the > implementations *should* check parameters (as they *should* check > all other stated preconditions) and when preconditions are violated, > a MathIllegalArgumentException is thrown. I don't care whether or > not we keep NAE. If we drop it, we should make sure whatever > exception messages we used to use to indicate illegal null arguments > are still there. > > Phil > I like this option better than 3. So, I'll change my "vote" to option #2, and possibly option #4 as we will never agree on option #2.
Best regards, Sébastien >> >> Your alternative (sometimes check, sometimes not) is not fully consistent: >> * for the user: "In case of null reference, will I get a >> MathRuntimeException >> or a NPE?" >> * for the CM developer: "In which cases do I need to check for null?" >> >> Of course, I would reconsider if you could provide an actual example that >> would fail with all three alternatives which I suggested. If not, then >> it seems obvious that your alternative presents two defects that don't exist >> in any of those three. >> >> >> Gilles >> >>>>> [...] 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
