Another perspective to think about is whether you want to write code like:
try {
// la-di-da
} catch (NullPointerException e) {
// garbage in!
}
or:
try {
// doo-wap-doo-wap
} catch (IllegalArugumentException e) {
// garbage in!
}
Catching NPE just smells funny to me.
Gary
On Fri, Aug 30, 2013 at 1:06 PM, sebb <seb...@gmail.com> wrote:
> The fact that NPE is documented in Bloch is quite important.
>
> Whatever we do choose, we should make sure to document all th reasons
> (pros and cons) somewhere other than just the mailing list!
>
> On 30 August 2013 17:30, Matt Benson <gudnabr...@gmail.com> wrote:
> > The discussion for [lang], none of whose participants have weighed in
> here,
> > took place in late 2009 (so perhaps a little longer ago than I thought)
> and
> > is archived at [1]. IMO Paul B. makes some pretty compelling arguments
> in
> > [2].
> >
> > Matt
> >
> > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >
> >
> > On Fri, Aug 30, 2013 at 11:13 AM, sebb <seb...@gmail.com> wrote:
> >
> >> 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
> >>
> >>
>
> ---------------------------------------------------------------------
> 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
