BTW, you can find precedence in the JVM for many methods that throw NPE on
null arguments. I am not saying this is the "right way", since such things
are subjective and are a matter of design, but many people have concluded
it's better.
On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker wrote:
>
>
> --
The recognised standard in the JDK is NPE on invalid null input.
I have never overly liked this, but conform to it for JSR-310/ThreeTen.
I use IAE in other projects which are higher up the stack. Whether
[math] is low or high level may determine the choice you make.
Personally, I don't use NullA
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
> > [...]
>
> I'm in favor of just letting the JVM throw NPE. Since there is no
> message in this case, there is nothing to localize. Using a class
> to check arguments is too much work, since the (localized) message
> "Something was null" is less than helpful. And assert will be
> turned off i
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
> The recognised standard in the JDK is NPE on invalid null input.
>
> I have never overly liked this, but conform to it for JSR-310/ThreeTen.
>
> I use IAE in other projects which are higher up the stack. Whether
> [math] is low or high level may determine the choice you make.
I've always heard
Hi Simon,
simonetrip...@apache.org wrote:
[snip]
> @@ -335,7 +335,7 @@ public interface Digester extends Conten
> *
> * @param object The new object
> */
> -void pushParams(Object object);
> +void pushParams(Object[] object);
>
> /**
> * Pop the top object
On 2 March 2011 08:20, Paul Benedict wrote:
> BTW, you can find precedence in the JVM for many methods that throw NPE on
> null arguments. I am not saying this is the "right way", since such things
> are subjective and are a matter of design, but many people have concluded
> it's better.
If the N
> > BTW, you can find precedence in the JVM for many methods that throw NPE on
> > null arguments. I am not saying this is the "right way", since such things
> > are subjective and are a matter of design, but many people have concluded
> > it's better.
>
> If the NPE would not be detected until th
On 2 March 2011 12:50, Gilles Sadowski wrote:
>> > BTW, you can find precedence in the JVM for many methods that throw NPE on
>> > null arguments. I am not saying this is the "right way", since such things
>> > are subjective and are a matter of design, but many people have concluded
>> > it's bet
Le 02/03/2011 12:37, Gilles Sadowski a écrit :
>> The recognised standard in the JDK is NPE on invalid null input.
>>
>> I have never overly liked this, but conform to it for JSR-310/ThreeTen.
>>
>> I use IAE in other projects which are higher up the stack. Whether
>> [math] is low or high level ma
Hi Jorg,
indeed, thanks for your feedback, very appreciated!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Mar 2, 2011 at 1:17 PM, Jörg Schaible
wrote:
> Hi Simon,
>
> simonetrip...@apache.org wrote:
>
> [snip]
>
>> @@ -335,7 +335,7 @@ public int
On Wed, Mar 02, 2011 at 01:11:48PM +, sebb wrote:
> On 2 March 2011 12:50, Gilles Sadowski wrote:
> >> > BTW, you can find precedence in the JVM for many methods that throw NPE
> >> > on
> >> > null arguments. I am not saying this is the "right way", since such
> >> > things
> >> > are subje
On 3/2/11 8:32 AM, Luc Maisonobe wrote:
> Le 02/03/2011 12:37, Gilles Sadowski a écrit :
>>> The recognised standard in the JDK is NPE on invalid null input.
>>>
>>> I have never overly liked this, but conform to it for JSR-310/ThreeTen.
>>>
>>> I use IAE in other projects which are higher up the s
I agree with this view. It would help the developer who uses CM if the
library told him/her what they did wrong ("argument 'foo' cannot be
null") instead of a simple exception thrown message
("NullPointerException thrown at line nnn of class Xyz").
-Adrian
On 3/2/2011 3:37 AM, Gilles Sadowsk
I neglected to mention that Commons Math *should* document what exceptions
are to be expected. If a method is designed to throw NPE because of a null
argument (whether through explicit checking or not), @throws should mention
that.
Paul
On Wed, Mar 2, 2011 at 10:36 AM, Adrian Crum <
adrian.c...@s
I consider it sufficient (preferable) to do the following:
@param foo the foo, not null
Where the ", not null" implies NPE when a null is passed in (document
once in the overview javadoc if you feel necessary). This approach is
easier to transfer to a @NotNull annotation in the future (or the
pro
The Apache Commons team is pleased to announce the release of version
2.2 of Commons Math. Commons Math is a library of lightweight,
self-contained mathematics and statistics components addressing the most
common problems not available in the Java programming language or
Commons Lang.
Version 2.2
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=3548&projectId=107
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 2 Mar 2011 18:20:39 +
Finished at: Wed 2 Mar 2011 18:20:51 +
Total time: 12s
Build Trigger: Schedule
Build Num
Hello.
> >> The recognised standard in the JDK is NPE on invalid null input.
> >>
> >> I have never overly liked this, but conform to it for JSR-310/ThreeTen.
> >>
> >> I use IAE in other projects which are higher up the stack. Whether
> >> [math] is low or high level may determine the choice you
I believe that the majority of exceptions should be in the same package and
not to under different ones...
> >>because most exceptions are general and thus I don't see the benefit of
> >>scattering the remaining few among several packages.
>
+1 for the proposal of Gilles
> 6) don't provide an
On 2 March 2011 22:55, wrote:
> Author: mbenson
> Date: Wed Mar 2 22:55:02 2011
> New Revision: 1076446
>
> URL: http://svn.apache.org/viewvc?rev=1076446&view=rev
> Log:
> add FilteredIterable
>
> Added:
>
> commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collecti
On Mar 2, 2011, at 6:19 PM, sebb wrote:
> On 2 March 2011 22:55, wrote:
>> Author: mbenson
>> Date: Wed Mar 2 22:55:02 2011
>> New Revision: 1076446
>>
>> URL: http://svn.apache.org/viewvc?rev=1076446&view=rev
>> Log:
>> add FilteredIterable
[SNIP]
>> +public class FilteredIterable implement
The http://commons.apache.org/releases/prepare.html site seems to
imply that the latest way to build the zip/tar.gzs is with:
mvn -Prc -DcreateChecksum=true install
Running that, I don't get what I'd expect.
Thought I'd report that. For now I'm going to use assembly:assembly.
Hen
---
Thanks Martin and Gary - sorry for my screwup.
Very happy that you found the Caverphone code however Martin :)
Hen
On Tue, Mar 1, 2011 at 9:59 AM, Gary Gregory wrote:
> The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
> release.
>
> Thank you,
> Gary
>
> On Tue, Mar 1, 20
Looking to release 3.0; there's not been a lot of JIRA activity and
it's 9 months or so since we released the beta.
Downloads:
http://people.apache.org/~bayard/commons-lang3-RC1/
Maven repo entry:
http://people.apache.org/~bayard/commons-lang3-RC1/maven/
Website:
http://people.apache.or
26 matches
Mail list logo
