commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Date Mon, 02 Sep 2013 23:02:13 GMT
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 <gudnabrsam@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 <james@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 <beneritter@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 <james@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 <gudnabrsam@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" <james@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 <britter@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 <garydgregory@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 <sebbaz@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
<gudnabrsam@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 <sebbaz@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 <sebbaz@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 <james@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


Mime
View raw message