You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2013/09/01 16:46:01 UTC
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
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 <ga...@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 <gu...@gmail.com> wrote:
>
> > How often do you really want to catch these?
> >
> > Matt
> >
> >
> > On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
> > > britter@apache.org
> > > > >
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >>> 2013/8/30 sebb <se...@gmail.com>
> > > > >> >>>
> > > > >> >>>> On 30 August 2013 15:19, Benedikt Ritter <britter@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 <se...@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 <
> > > > james@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 <
> > > > >> >>>>
> > > > >> >>>> garydgregory@gmail.com>
> > > > >> >>>>>>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> > > > >> >>>
> > > > >> >>> ebourg@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-unsubscribe@commons.apache.org
> > > > >> >>>>>>>>>> For additional commands, e-mail:
> > > dev-help@commons.apache.org
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> --
> > > > >> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> > > > >> >>>>>>>> For additional commands, e-mail:
> > dev-help@commons.apache.org
> > > > >> >>>>>>>>
> > > > >> >>>>>>>
> > > > >> >>>
> > > > ---------------------------------------------------------------------
> > > > >> >>>>>>>
> > > > >> >>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > > > >> >>>>>>> For additional commands, e-mail:
> > dev-help@commons.apache.org
> > > > >> >>>>>>>
> > > > >> >>>>>>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> >>>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@commons.apache.org
> > > > >> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> > > > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >> >
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > > >>
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/09/2013 20:46, James Carman a écrit :
> Emmanuel was the only dissenting voice, perhaps he would want to weigh
> in at this point. Emmanuel?
I asked because I was under the impression that throwing a NPE in this
case was the most common practice. But I don't care much as long as the
exception message is explicit.
Emmanuel Bourg
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Phil Steitz <ph...@gmail.com>.
On 9/2/13 3:30 PM, James Carman wrote:
> 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.
I do as well. The key for me is Gary's point about activation site
- where exactly the exception is triggered. If it is detected at an
API boundary, then IAE makes sense to me. I like (where practical)
to document null handling in API documentation and if the
documentation says nulls are not allowed, throw IAE. I don't like
the "just let the runtime go boom" approach when I can avoid it. As
a user, I would much rather see an IAE where a (documented) null
check failed than an NPE bubbling up from the bowels of some impl
that I don't know anything about.
An analogous case that may not convince anyone is to consider
ArrayIndexOutOfBoundsException triggered when an API is given bad
array indices. There as well, I would see a) failfast better and b)
IAE thrown instead of AIOOBE.
All that said, we more or less agreed on a different approach for
[math] [1], so I understand above may be a minority view.
Phil
[1] http://markmail.org/message/cl2e6c4pqbluo63e
>
> On Mon, Sep 2, 2013 at 3:27 PM, Matt Benson <gu...@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 <be...@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 <gu...@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 <garydgregory@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 <br...@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 <ga...@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 <
>>> gudnabrsam@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>> How often do you really want to catch these?
>>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>>>>> garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>>>>>>>>>>>> britter@apache.org
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>>>>> britter@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 <
>>> sebbaz@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 <
>>>>>>>>>>>>> james@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 <
>>>>>>>>>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
>>> ggregory@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>> dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
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 <gu...@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 <be...@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 <gu...@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 <garydgregory@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 <br...@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 <ga...@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 <
>> gudnabrsam@gmail.com>
>> >> >> wrote:
>> >> >> >>>
>> >> >> >>>> How often do you really want to catch these?
>> >> >> >>>>
>> >> >> >>>> Matt
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>> >> garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>> >> >> >>>>> britter@apache.org
>> >> >> >>>>>>>
>> >> >> >>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>> >> britter@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 <
>> sebbaz@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 <
>> >> >> >>>>>> james@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 <
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> garydgregory@gmail.com>
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>>> dev-help@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> --
>> >> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
>> ggregory@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-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>> dev-help@commons.apache.org
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >> >>> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>> dev-help@commons.apache.org
>> >> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>> dev-help@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-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>> For additional commands, e-mail:
>> >> dev-help@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-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
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 <be...@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 <gu...@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 <garydgregory@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 <br...@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 <ga...@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 <
> gudnabrsam@gmail.com>
> >> >> wrote:
> >> >> >>>
> >> >> >>>> How often do you really want to catch these?
> >> >> >>>>
> >> >> >>>> Matt
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> >> garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
> >> >> >>>>> britter@apache.org
> >> >> >>>>>>>
> >> >> >>>>>>>>>> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
> >> britter@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 <
> sebbaz@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 <
> >> >> >>>>>> james@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 <
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>>> dev-help@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> --
> >> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
> ggregory@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>> dev-help@commons.apache.org
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >> >>> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>> dev-help@commons.apache.org
> >> >> >>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>> dev-help@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>> For additional commands, e-mail:
> >> dev-help@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-unsubscribe@commons.apache.org
> >> >> >>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >> >>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> --
> >> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
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 <be...@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 <gu...@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 <ga...@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 <br...@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 <ga...@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 <gu...@gmail.com>
>> >> wrote:
>> >> >>>
>> >> >>>> How often do you really want to catch these?
>> >> >>>>
>> >> >>>> Matt
>> >> >>>>
>> >> >>>>
>> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>> garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>> >> >>>>> britter@apache.org
>> >> >>>>>>>
>> >> >>>>>>>>>> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>> britter@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 <se...@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 <
>> >> >>>>>> james@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 <
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> garydgregory@gmail.com>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>>> dev-help@commons.apache.org
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> --
>> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>> dev-help@commons.apache.org
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>> dev-help@commons.apache.org
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>> dev-help@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-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>> For additional commands, e-mail:
>> dev-help@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-unsubscribe@commons.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Benedikt Ritter <be...@gmail.com>.
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 <gu...@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 <ga...@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 <br...@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 <ga...@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 <gu...@gmail.com>
> >> wrote:
> >> >>>
> >> >>>> How often do you really want to catch these?
> >> >>>>
> >> >>>> Matt
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
> >> >>>>> britter@apache.org
> >> >>>>>>>
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
> britter@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 <se...@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 <
> >> >>>>>> james@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 <
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>>> dev-help@commons.apache.org
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>> dev-help@commons.apache.org
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >>> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>> dev-help@commons.apache.org
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>> dev-help@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-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@commons.apache.org
> >> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by 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 <gu...@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 <ga...@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 <br...@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 <ga...@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 <gu...@gmail.com>
>> wrote:
>> >>>
>> >>>> How often do you really want to catch these?
>> >>>>
>> >>>> Matt
>> >>>>
>> >>>>
>> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>> >>>>> britter@apache.org
>> >>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@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 <se...@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 <
>> >>>>>> james@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 <
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> garydgregory@gmail.com>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >>>>>>>>>>>
>> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>>> dev-help@commons.apache.org
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>> dev-help@commons.apache.org
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >>> dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>> dev-help@commons.apache.org
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >>> dev-help@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-unsubscribe@commons.apache.org
>> >>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
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 <ga...@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 <br...@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 <ga...@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 <gu...@gmail.com>
> wrote:
> >>>
> >>>> How often do you really want to catch these?
> >>>>
> >>>> Matt
> >>>>
> >>>>
> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
> >>>>> britter@apache.org
> >>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@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 <se...@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 <
> >>>>>> james@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 <
> >>>>>>>>>>>>
> >>>>>>>>>>>> garydgregory@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >>>>>>>>>>>
> >>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>> dev-help@commons.apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>> dev-help@commons.apache.org
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>> dev-help@commons.apache.org
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> >>> dev-help@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-unsubscribe@commons.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>>> --
> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ga...@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 <br...@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 <ga...@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 <gu...@gmail.com> wrote:
>>>
>>>> How often do you really want to catch these?
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>>>>> britter@apache.org
>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@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 <se...@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 <
>>>>>> james@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 <
>>>>>>>>>>>>
>>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>>
>>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
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 <br...@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 <ga...@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 <gu...@gmail.com> wrote:
>>
>>> How often do you really want to catch these?
>>>
>>> Matt
>>>
>>>
>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@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 <se...@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 <gu...@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 <se...@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.crum@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 <
>>>> britter@apache.org
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@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 <se...@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 <
>>>>> james@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 <
>>>>>>>>>>>
>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>
>>>>>>>>>> ebourg@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail:
>> dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org