commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [lang] ArrayUtils.toPrimitive and NPEs.
Date Wed, 05 Oct 2005 00:14:36 GMT
Actually, if you read the javadocs for NullPointerException, it says that
"Applications should throw instances of this class to indicate other illegal
uses of the null object."  However, I agree with you.  I like
IllegalArgumentException or its NullArgumentException subclass (which I was
unaware of until just the other day) for these types of situations.
NullArgumentException should probably be moved to the exception package, by
the way (that's where I first looked for it).

-----Original Message-----
From: Gary Gregory [mailto:ggregory@seagullsoftware.com] 
Sent: Tuesday, October 04, 2005 5:45 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] ArrayUtils.toPrimitive and NPEs.

> I think that the basic reasoning is/was to have a validating version
and
> a non-validating version of the same method.

Perhaps, but if the intention was to say that nulls are illegal, letting
NPE be thrown seem like a poor design decision to me as opposed to
explicitly stating this intent with an IllegalArgumentException.

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Tuesday, October 04, 2005 2:22 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] ArrayUtils.toPrimitive and NPEs.
> 
> Gary Gregory wrote:
> > Hello:
> >
> > WRT: http://issues.apache.org/bugzilla/show_bug.cgi?id=36915
> >
> > All of the ArrayUtils.toPrimitive one arg methods all NPE when an
input
> > element is null. Why would you want that?
> >
> > We have a handy two arg version of the methods that allows a default
> > value to be passed in. Since primitives *have* default values, why
not
> > simply allow nulls not to NPE and take on the default primitive
value?
> > Seems easy enough to change...
> 
> But it would have compatability issues. At the very least its a
semantic
> change.
> 
> I think that the basic reasoning is/was to have a validating version
and
> a non-validating version of the same method.
> 
> So I guess I'm -0.
> 
> Stephen
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message