The JDK Javadoc says of NPE:
* Applications should throw instances of this class to indicate
* other illegal uses of the <code>null</code> object.
and of IAE:
* Thrown to indicate that a method has been passed an illegal or
* inappropriate argument.
That says to me that we should throw IAE here.
The JDK does use NPE for parameter checks, but it also uses IAE, for example:
javax.management.monitor.Monitor.addObservedObject
java.rmi.activation.ActivationDesc.ActivationDesc
javax.management.relation.RoleList.add
javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
On 30 August 2013 16:50, Adrian Crum <adrian.c...@sandglass-software.com> wrote:
> I've seen a lot of discussions on NPE versus IAE, and in the end they all
> condense down to what Matt stated here: Those who favor NPE cite the JDK
> classes as a pattern to follow, and those who favor IAE say it is a better
> description of the problem. From my perspective, both are valid viewpoints,
> and a project simply needs to choose one. In the end, the choice is neither
> "right" nor "wrong" - it is just a choice.
>
> -Adrian
>
>
>
> On 8/30/2013 8:07 AM, Matt Benson wrote:
>>
>> Let me stir the pot:
>> At a fundamental level I agree that a required *argument* should throw
>> an
>> IllegalArgumentException when null is supplied. However, ISTR the
>> decision
>> to do otherwise in [lang] having been discussed on-list in the
>> not-so-distant past, and the result of that discussion being that NPE is
>> usually the result in the core JDK classes. So I wouldn't characterize
>> the
>> situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
>> slightly unique situation as its stated mission is to complement Java SE,
>> so it could be argued that [lang] is under greater pressure to conform for
>> that reason. But my personal preference, in light of the standing
>> decision
>> with [lang], would be for consistency throughout Commons components
>> *despite* the fact that at a purely semantic level I agree with the
>> arguments in favor of IllegalArgumentException.
>>
>> To summarize, +1 for NullPointerException from me.
>>
>> Matt
>>
>>
>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <brit...@apache.org>
>> wrote:
>>
>>> 2013/8/30 sebb <seb...@gmail.com>
>>>
>>>> On 30 August 2013 15:19, Benedikt Ritter <brit...@apache.org> wrote:
>>>>>
>>>>> I've removed the generics in r1518974, thanks for spotting that sebb.
>>>>>
>>>>> Regarding the exception to throw I'm indifferent. The important thing
>>>
>>> is
>>>>
>>>> to
>>>>>
>>>>> fail early.
>>>>>
>>>> ... and with a helpful message.
>>>>
>>>>> I personally thing that NPE should be reserved for signaling that some
>>>>
>>>> code
>>>>>
>>>>> tried to invoke a method on a null reference.
>>>>
>>>> +1
>>>>
>>>>> In our case null is illegal because we know that some code later on
>>>
>>> would
>>>>>
>>>>> break if we accept a null reference. So IllegalStateException makes
>>>>
>>>> sense.
>>>>
>>>> s/IllegalStateException /IllegalArgumentException/
>>>>
>>>> +1
>>>>
>>> Sorry, I meant IAE of corse.
>>>
>>>
>>>>> Imaging having a method that accepts an int and only positive ints are
>>>>> valid. You would throw an IllegalArgumentException if a negative int is
>>>>> passed to that method and not a NegativeIntegerException (or what
>>>
>>> ever).
>>>>>
>>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
>>>
>>> this.
>>>>
>>>> I don't think we have to do the same as LANG, so long as the Javadoc is
>>>> clear.
>>>>
>>>>> Feel free to change it. I'll leave it for now since there doesn't seem
>>>
>>> to
>>>>>
>>>>> be consensus?!
>>>>
>>>> Unless there are other reasons than "LANG happens to use NPE" I think
>>>> we should stick with IAE, as it more clearly indicates the the problem
>>>> is not within the method throwing it.
>>>>
>>>> The problem with using NPE to flag parameter errors is that it
>>>> confuses the user as to the likely cause.
>>>>
>>>> Leave NPEs to the runtime system.
>>>>
>>> agreed.
>>>
>>>
>>>>> Benedikt
>>>>>
>>>>>
>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>>
>>>>>> Well, the problem with using NPE is that we as Java developers have
>>>>>> learned through the years that NPE typically is an "oh crap"
>>>>>> situation, where something is terribly wrong (we hate seeing those).
>>>>>> Thus, our users may have knee-jerk reactions and not even know to
>>>>>> inspect the message for the real cause. IAE is less alarming, IMHO.
>>>>>> Just my $0.02, but we've been doing it that way for a long time in
>>>>>> [lang], so be it.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <seb...@gmail.com> wrote:
>>>>>>>
>>>>>>> AFAIK "accidental" NPEs don't have a message associated with them.
>>>>>>>
>>>>>>> So provided that the assertion generates the NPE with a suitable
>>>>>>> message (e.g.as currently done for the IAE) then it *should* be
>>>>>>> possible for the end user to distinguish the two cases.
>>>>>>>
>>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
>>>
>>> with
>>>>>>>
>>>>>>> needing to look at the NPE message.
>>>>>>>
>>>>>>> ==
>>>>>>>
>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE in
>>>
>>> the
>>>>>>
>>>>>> NPE:
>>>>>>>
>>>>>>> npe = new NPE(msg);
>>>>>>> npe.initCause(new IAE(msg));
>>>>>>> throw npe;
>>>>>>>
>>>>>>> Or vice-vera, of course!
>>>>>>>
>>>>>>> Not sure that gains anything, but it does make the stack trace look
>>>>>>> more impressive!
>>>>>>>
>>>>>>> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know that
>>>>
>>>> I've
>>>>>>>>
>>>>>>>> necessarily agreed with that, but at some point a decision was made
>>>>>>>> that null constraint violations should throw NPEs. Food for
>>>
>>> thought.
>>>>>>>>
>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>>>
>>>> garydgreg...@gmail.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>
>>> ebo...@apache.org>
>>>>>>
>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>>> + throw new IllegalArgumentException("Parameter '"
>>>
>>> +
>>>>>>>>>>
>>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>>>
>>>>>>>>>>>> + }
>>>>>>>>>>>> + }
>>>>>>>>>>>> +}
>>>>>>>>>>
>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>>
>>>>>>>>> Not always IMO. When I see an NPE I assume something is very wrong
>>>>
>>>> and
>>>>>>
>>>>>> that
>>>>>>>>>
>>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
>>>
>>> code
>>>>>>
>>>>>> path.
>>>>>>>>>
>>>>>>>>> With an IAE, I know for sure it's a problem in the call site
>>>
>>> (which
>>>>>>
>>>>>> could
>>>>>>>>>
>>>>>>>>> be a bug of course).
>>>>>>>>>
>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's hard to
>>>>
>>>> find
>>>>>>>>>
>>>>>>>>> examples.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Emmanuel Bourg
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>>>
>>>>>> http://www.manning.com/bauer3/>
>>>>>>>>>
>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> http://people.apache.org/~britter/
>>>>> http://www.systemoutprintln.de/
>>>>> http://twitter.com/BenediktRitter
>>>>> http://github.com/britter
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>>
>
>
> ---------------------------------------------------------------------
> 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
