I get both sides of the argument. I just know how I feel when I see
an NPE. It's probably more of a psychological thing for me, I guess.
I just prefer IAE in these cases.
On Mon, Sep 2, 2013 at 3:27 PM, Matt Benson <gudnabr...@gmail.com> wrote:
> To continue to play devil's advocate, when one validates that an argument
> is not null, doesn't this signify that in the absence of such validation,
> NPE is what would be thrown anyway? Arguably throwing NPE from
> Validate#notNull() simply allows the API designer to explicitly address
> this and optionally provide a more detailed exception message in the
> process.
>
> Matt
>
>
> On Mon, Sep 2, 2013 at 1:46 PM, James Carman
> <ja...@carmanconsulting.com>wrote:
>
>> I think Emmanuel Bourg was the only one actually advocating NPE (or
>> asking if it's what should be used). I brought up the fact that
>> [lang] uses NPE merely as a discussion point. I don't agree with the
>> NPE usage for Validate.notNull() (sorry I was not more clear on that
>> opinion). I would rather have all of Validate's methods throw IAE for
>> consistency. As far as this case is concerned, the only thing you
>> would have to worry about would be a veto from someone, and since
>> Emmanuel was the only dissenting voice, perhaps he would want to weigh
>> in at this point. Emmanuel?
>>
>> I don't know if I would agree that Bloch has "codified this
>> expectation into the minds of developers." I've been developing in
>> Java for a long time and when I see a NPE, I immediately think this
>> results from an attempt to dereference a null reference. Judging from
>> the discussion here, I would think others feel the same way.
>>
>> On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <benerit...@gmail.com>
>> wrote:
>> > Hey,
>> >
>> > sorry if I missunderstood your opinions (Gary and James).
>> > So do we call for a [VOTE]? I've never seen a vote thread for design
>> > related decisions so far.
>> >
>> > Benedikt
>> >
>> >
>> > 2013/9/2 James Carman <ja...@carmanconsulting.com>
>> >
>> >> I meant re-visit the decision to make sure we took everything into
>> >> consideration when choosing which way to go in this case. I say we
>> >> leave [lang] alone at this point.
>> >>
>> >>
>> >> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gudnabr...@gmail.com>
>> wrote:
>> >> > How do you mean, "revisit?" I think changing [lang] at this late date
>> >> would
>> >> > be more trouble than it's worth.
>> >> >
>> >> > Matt
>> >> > On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
>> >> wrote:
>> >> >
>> >> >> I favor IAE, but I want to make sure we re-visit the decision made
>> for
>> >> >> [lang] when it chose to use NPE instead.
>> >> >>
>> >> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgreg...@gmail.com
>> >
>> >> >> wrote:
>> >> >> > It feels to me that this misrepresents the ideas expressed here,
>> or at
>> >> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE,
>> so
>> >> >> > does that mean I am nor "most people". If a person make these
>> kinds of
>> >> >> > statement, we might as well VOTE or argue-discuss some more...!
>> >> >> >
>> >> >> > Gary
>> >> >> >
>> >> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <brit...@apache.org>
>> wrote:
>> >> >> >
>> >> >> >> Look's like most people are either indifferent or favor NPE. So,
>> do
>> >> we
>> >> >> >> change this for [CSV]? The important thing is to give users an
>> >> >> expressive
>> >> >> >> message.
>> >> >> >>
>> >> >> >> Benedikt
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> 2013/8/30 Gary Gregory <garydgreg...@gmail.com>
>> >> >> >>
>> >> >> >>> Surprisingly, a lot. At work, we have a lot of
>> >> frameworky/plugin-type
>> >> >> of
>> >> >> >>> code where we run operations on collections of things and we do
>> not
>> >> >> want
>> >> >> >>> "expected" errors to torpedo the whole processing flow, so we do
>> >> catch
>> >> >> >>> things like IAE and ISE. We do try to avoid catching Exception
>> if we
>> >> >> can
>> >> >> >>> help it.
>> >> >> >>>
>> >> >> >>> Gary
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <
>> gudnabr...@gmail.com>
>> >> >> wrote:
>> >> >> >>>
>> >> >> >>>> How often do you really want to catch these?
>> >> >> >>>>
>> >> >> >>>> Matt
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>> >> garydgreg...@gmail.com
>> >> >> >>>>> wrote:
>> >> >> >>>>
>> >> >> >>>>> 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
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> 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
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> 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
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> 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
