Hi.
> [...]
>
> >> I was about to start a new thread too, but refrained to do so for lack
> >> of knowledge on the history of this particular exception.
> >> Check for null is unevenly enforced througout the library, which --to
> >> me-- suggests we shouldn't do it at all and contend wit
> > [...]
> >>
> >Do you mean that we should do nothing, and let NPE occur "naturally"?
> >The origin of the problem might then be difficult to identify.
> >Or maybe you meant that we check for null in that case, but throw NPE
> >instead of our own MathNullArgument?
> >I would be in favor of the se
On 9/6/12 5:16 AM, Gilles Sadowski wrote:
> Hi.
>
>> [...]
>>
I was about to start a new thread too, but refrained to do so for lack
of knowledge on the history of this particular exception.
Check for null is unevenly enforced througout the library, which --to
me-- sugge
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-856
cannot reach a consensus on solving the issue that raised this thread.
The proposal was that CM never checks for "null" and lets the JVM do it (and
thus throw the standard NPE).
Phil wants to retain some nul
On 9/9/12 4:34 AM, Gilles Sadowski wrote:
> Hi.
>
> Further discussion on the JIRA page
> https://issues.apache.org/jira/browse/MATH-856
> cannot reach a consensus on solving the issue that raised this thread.
>
> The proposal was that CM never checks for "null" and lets the JVM do it (and
> thus
On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
> > Hi.
> >
> > Further discussion on the JIRA page
> > https://issues.apache.org/jira/browse/MATH-856
> > cannot reach a consensus on solving the issue that raised this thread.
> >
> > The pr
On 9/9/12 3:26 PM, Gilles Sadowski wrote:
> On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
>> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
>>> Hi.
>>>
>>> Further discussion on the JIRA page
>>> https://issues.apache.org/jira/browse/MATH-856
>>> cannot reach a consensus on solving the
Yes. One example is the constructor for EmpiricalDistribution that
takes a RandomGenerator as argument. If a null is supplied, the
constructor does not complain and the lazy initialization works as
though the argumentless constructor had been used and a JDK random
generator is created. There
Hi,
2012/9/10 Gilles Sadowski :
> On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
>> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
>> > Hi.
>> >
>> > Further discussion on the JIRA page
>> > https://issues.apache.org/jira/browse/MATH-856
>> > cannot reach a consensus on solving the issu
Le 10/09/2012 08:11, Sébastien Brisard a écrit :
> Hi,
>
> 2012/9/10 Gilles Sadowski :
>> On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
>>> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/M
> > [...]
> >
> > P.S. Is there an occurrence in CM, where a method can be passed a null
> > argument?
>
> Yes. One example is the constructor for EmpiricalDistribution that
> takes a RandomGenerator as argument.
Thanks for finding one of those few examples.
The first remark (concerning th
On 9/10/12 3:44 AM, Gilles Sadowski wrote:
>>> [...]
>>>
>>> P.S. Is there an occurrence in CM, where a method can be passed a null
>>> argument?
>> Yes. One example is the constructor for EmpiricalDistribution that
>> takes a RandomGenerator as argument.
> Thanks for finding one of those fe
On 9/9/12 11:11 PM, Sébastien Brisard wrote:
> Hi,
>
> 2012/9/10 Gilles Sadowski :
>> On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
>>> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
Hi.
Further discussion on the JIRA page
https://issues.apache.org/jira/browse/MATH-8
Hi
What should I do there?
I'm trying to work on MATH-854. It turns out that FieldElement.add
throws a NAE. Should I catch it below, and rethrow it with a more
detailed message (including the entry index)?
Best,
Sébastien
/** {@inheritDoc} */
public FieldVector add(FieldVector v)
On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> Hi
> What should I do there?
> I'm trying to work on MATH-854. It turns out that FieldElement.add
> throws a NAE. Should I catch it below, and rethrow it with a more
> detailed message (including the entry index)?
IMO, yes.
I would also check v itse
On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote:
> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> > Hi
> > What should I do there?
> > I'm trying to work on MATH-854. It turns out that FieldElement.add
> > throws a NAE. Should I catch it below, and rethrow it with a more
> > detailed m
Hey,
I'm a disinterested third party (not a CM user) but I thought I should
chime in my two cents worth...
On Sun, Sep 9, 2012 at 4:34 AM, Gilles Sadowski
wrote:
> Hi.
>
> Further discussion on the JIRA page
> https://issues.apache.org/jira/browse/MATH-856
> cannot reach a consensus on solving
On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
> Hi
> What should I do there?
If we adopt the "flexible" policy (cf. other post), then you can do what you
want. ;-)
> I'm trying to work on MATH-854. It turns out that FieldElement.add
> throws a NAE. Should I catch it below, an
On 9/10/12 3:46 PM, Gilles Sadowski wrote:
> On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
>> Hi
>> What should I do there?
> If we adopt the "flexible" policy (cf. other post), then you can do what you
> want. ;-)
Good one :)
>
>> I'm trying to work on MATH-854. It turns out
On 9/10/12 3:43 PM, James Ring wrote:
> Hey,
>
> I'm a disinterested third party (not a CM user) but I thought I should
> chime in my two cents worth...
>
> On Sun, Sep 9, 2012 at 4:34 AM, Gilles Sadowski
> wrote:
>> Hi.
>>
>> Further discussion on the JIRA page
>> https://issues.apache.org/jira
Hey Phil
On Mon, Sep 10, 2012 at 5:09 PM, Phil Steitz wrote:
> On 9/10/12 3:43 PM, James Ring wrote:
>>> try {
>>>// Call CM
>>> } catch (NullPointerException e) {
>>>// Handle NPE (raised by the JVM _or_ by CM).
>>> }
>> Is this going to be the typical case? NPE indicates a programmin
Hello,
2012/9/11 Gilles Sadowski :
> On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote:
>> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>> > Hi
>> > What should I do there?
>> > I'm trying to work on MATH-854. It turns out that FieldElement.add
>> > throws a NAE. Should I catch it below
Hi,
2012/9/11 Gilles Sadowski :
> On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
>> Hi
>> What should I do there?
>
> If we adopt the "flexible" policy (cf. other post), then you can do what you
> want. ;-)
>
This is absolutely what I do not want to do... I've already realized
Hi Sébastien.
>
> 2012/9/11 Gilles Sadowski :
> > On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote:
> >> Hi
> >> What should I do there?
> >
> > If we adopt the "flexible" policy (cf. other post), then you can do what you
> > want. ;-)
> >
> This is absolutely what I do not want
On Tue, Sep 11, 2012 at 07:46:20AM +0200, Sébastien Brisard wrote:
> Hello,
>
> 2012/9/11 Gilles Sadowski :
> > On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote:
> >> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> >> > Hi
> >> > What should I do there?
> >> > I'm trying to work on MATH
Hi Phil,
2012/9/10 Phil Steitz :
> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>> Hi
>> What should I do there?
>> I'm trying to work on MATH-854. It turns out that FieldElement.add
>> throws a NAE. Should I catch it below, and rethrow it with a more
>> detailed message (including the entry inde
On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> Hi Phil,
>
> 2012/9/10 Phil Steitz :
> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> >> Hi
> >> What should I do there?
> >> I'm trying to work on MATH-854. It turns out that FieldElement.add
> >> throws a NAE. Should I catch
Hi Gilles,
2012/9/12 Gilles Sadowski :
> On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>> Hi Phil,
>>
>> 2012/9/10 Phil Steitz :
>> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>> >> Hi
>> >> What should I do there?
>> >> I'm trying to work on MATH-854. It turns out that Fi
On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
> Hi Gilles,
>
> 2012/9/12 Gilles Sadowski :
> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> >> Hi Phil,
> >>
> >> 2012/9/10 Phil Steitz :
> >> > On 9/10/12 11:47 AM, Sébastien Brisard wrote:
> >> >> Hi
> >
2012/9/12 Gilles Sadowski :
> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>> Hi Gilles,
>>
>> 2012/9/12 Gilles Sadowski :
>> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>> >> Hi Phil,
>> >>
>> >> 2012/9/10 Phil Steitz :
>> >> > On 9/10/12 11:47 AM, Sé
On 9/12/12 5:14 AM, Sébastien Brisard wrote:
> 2012/9/12 Gilles Sadowski :
>> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>>> Hi Gilles,
>>>
>>> 2012/9/12 Gilles Sadowski :
On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
> Hi Phil,
>
> 2012
> [...]
>
> I know this is a little of a sore subject, but in this and other
> cases where arguments violate documented preconditions, I think we
> should throw IAE, which means MNAE is only appropriate as long as it
> continues to subclass our surrogate for IAE - MIAE.
>
> If I sound hard-headed
On 9/12/12 8:52 AM, Gilles Sadowski wrote:
>> [...]
>>
>> I know this is a little of a sore subject, but in this and other
>> cases where arguments violate documented preconditions, I think we
>> should throw IAE, which means MNAE is only appropriate as long as it
>> continues to subclass our surro
Hello.
[For those who don't wish to read the whole post, please at least go towards
the end and indicate your preferred option. Thanks.]
> > [...]
> >> All are bad arguments violating API contract,
> >> all detected at method activation time -> IAE.
> > Agreed... if the policy is to _always_ chec
On Thu, Sep 13, 2012 at 01:10:41AM +0200, Gilles Sadowski wrote:
> Hello.
>
> [For those who don't wish to read the whole post, please at least go towards
> the end and indicate your preferred option. Thanks.]
>
> [... long post skipped ...]
>
> Back to square one, with 3 fully consistent altern
fang.homelinux.org]
Sent: Thursday, September 13, 2012 10:36 AM
To: dev@commons.apache.org
Subject: Re: [Math] About "NullArgumentException"
On Thu, Sep 13, 2012 at 01:10:41AM +0200, Gilles Sadowski wrote:
> Hello.
>
> [For those who don't wish to read the whole post, pleas
Hi,
2012/9/13 Gilles Sadowski :
> On Thu, Sep 13, 2012 at 01:10:41AM +0200, Gilles Sadowski wrote:
>> Hello.
>>
>> [For those who don't wish to read the whole post, please at least go towards
>> the end and indicate your preferred option. Thanks.]
>>
>> [... long post skipped ...]
>>
>> Back to sq
Hi.
On Thu, Sep 13, 2012 at 01:34:38PM -0400, Kish, Robert wrote:
> Hello -
> I've been following this mailing list for a few months, and I
> feel this is a good opportunity to provide a first opinion on a topic.
>
> I find option 2, to never check for null, the best option. But, I think
>
On 9/12/12 4:10 PM, Gilles Sadowski wrote:
> Hello.
>
> [For those who don't wish to read the whole post, please at least go towards
> the end and indicate your preferred option. Thanks.]
>
>>> [...]
All are bad arguments violating API contract,
all detected at method activation time -> I
Hi Phil
>>
>> Back to square one, with 3 fully consistent alternatives:
>> 1. CM to always check for null? Then "NullArgumentException" inheriting from
>> "MathIllegalArgumentException" is fine because we promise to the user
>> that
>> no NPE will ever propagate through the CM layer. [Br
Le 14/09/2012 08:46, Sébastien Brisard a écrit :
> Hi Phil
>
>>>
>>> Back to square one, with 3 fully consistent alternatives:
>>> 1. CM to always check for null? Then "NullArgumentException" inheriting
>>> from
>>> "MathIllegalArgumentException" is fine because we promise to the user
>>> t
On Fri, Sep 14, 2012 at 10:41:50AM +0200, Luc Maisonobe wrote:
> Le 14/09/2012 08:46, Sébastien Brisard a écrit :
> > Hi Phil
> >
> >>>
> >>> Back to square one, with 3 fully consistent alternatives:
> >>> 1. CM to always check for null? Then "NullArgumentException" inheriting
> >>> from
> >>>
Hi Gilles,
2012/9/14 Gilles Sadowski :
> On Fri, Sep 14, 2012 at 10:41:50AM +0200, Luc Maisonobe wrote:
>> Le 14/09/2012 08:46, Sébastien Brisard a écrit :
>> > Hi Phil
>> >
>> >>>
>> >>> Back to square one, with 3 fully consistent alternatives:
>> >>> 1. CM to always check for null? Then "NullAr
On 9/14/12 4:28 AM, Gilles Sadowski wrote:
> On Fri, Sep 14, 2012 at 10:41:50AM +0200, Luc Maisonobe wrote:
>> Le 14/09/2012 08:46, Sébastien Brisard a écrit :
>>> Hi Phil
>>>
> Back to square one, with 3 fully consistent alternatives:
> 1. CM to always check for null? Then "NullArgumentEx
On Fri, Sep 14, 2012 at 07:44:08AM -0700, Phil Steitz wrote:
> On 9/14/12 4:28 AM, Gilles Sadowski wrote:
> > On Fri, Sep 14, 2012 at 10:41:50AM +0200, Luc Maisonobe wrote:
> >> Le 14/09/2012 08:46, Sébastien Brisard a écrit :
> >>> Hi Phil
> >>>
> > Back to square one, with 3 fully consistent
OK, I give up. Lets do option 2. Just warn users in the User Guide
somewhere that our APIs are in general not null-safe and unless the
javadoc explicitly allows nulls, they can expect NPE when passing nulls.
Phil
On 9/14/12 8:46 AM, Gilles Sadowski wrote:
> On Fri, Sep 14, 2012 at 07:44:08AM -0
On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
> OK, I give up. Lets do option 2. Just warn users in the User Guide
> somewhere that our APIs are in general not null-safe and unless the
> javadoc explicitly allows nulls, they can expect NPE when passing nulls.
Thanks, Phil; we are
Le 17/09/2012 11:50, Gilles Sadowski a écrit :
> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
>> OK, I give up. Lets do option 2. Just warn users in the User Guide
>> somewhere that our APIs are in general not null-safe and unless the
>> javadoc explicitly allows nulls, they can e
Hi Gilles,
2012/9/17 Luc Maisonobe :
> Le 17/09/2012 11:50, Gilles Sadowski a écrit :
>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
>>> OK, I give up. Lets do option 2. Just warn users in the User Guide
>>> somewhere that our APIs are in general not null-safe and unless the
>>>
Hello,
2012/9/17 Gilles Sadowski :
> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
>> OK, I give up. Lets do option 2. Just warn users in the User Guide
>> somewhere that our APIs are in general not null-safe and unless the
>> javadoc explicitly allows nulls, they can expect NPE w
On 9/18/12 12:02 PM, Sébastien Brisard wrote:
> Hello,
>
> 2012/9/17 Gilles Sadowski :
>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
>>> OK, I give up. Lets do option 2. Just warn users in the User Guide
>>> somewhere that our APIs are in general not null-safe and unless the
>>>
Hi,
2012/9/18 Phil Steitz :
> On 9/18/12 12:02 PM, Sébastien Brisard wrote:
>> Hello,
>>
>> 2012/9/17 Gilles Sadowski :
>>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
OK, I give up. Lets do option 2. Just warn users in the User Guide
somewhere that our APIs are in gen
On 9/19/12 12:12 AM, Sébastien Brisard wrote:
> Hi,
>
> 2012/9/18 Phil Steitz :
>> On 9/18/12 12:02 PM, Sébastien Brisard wrote:
>>> Hello,
>>>
>>> 2012/9/17 Gilles Sadowski :
On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
> OK, I give up. Lets do option 2. Just warn users
On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
> Author: luc
> Date: Wed Sep 5 18:30:08 2012
> New Revision: 1381284
>
> URL: http://svn.apache.org/viewvc?rev=1381284&view=rev
> Log:
> Added throw declarations for package complex.
>
> Modified:
>
> commons/proper/math/trun
On 5 September 2012 22:46, Gilles Sadowski wrote:
> On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
>> Author: luc
>> Date: Wed Sep 5 18:30:08 2012
>> New Revision: 1381284
>>
>> URL: http://svn.apache.org/viewvc?rev=1381284&view=rev
>> Log:
>> Added throw declarations for packag
Hi Gilles,
2012/9/6 sebb :
> On 5 September 2012 22:46, Gilles Sadowski
> wrote:
>> On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
>>> Author: luc
>>> Date: Wed Sep 5 18:30:08 2012
>>> New Revision: 1381284
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1381284&view=rev
>>> Log
Hi all,
Le 2012-09-06 07:08, Sébastien Brisard a écrit :
Hi Gilles,
2012/9/6 sebb :
On 5 September 2012 22:46, Gilles Sadowski
wrote:
On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
Author: luc
Date: Wed Sep 5 18:30:08 2012
New Revision: 1381284
URL: http://svn.apache.org
Hi Luc,
2012/9/6 luc :
> Hi all,
>
> Le 2012-09-06 07:08, Sébastien Brisard a écrit :
>
>> Hi Gilles,
>>
>> 2012/9/6 sebb :
>>>
>>> On 5 September 2012 22:46, Gilles Sadowski
>>> wrote:
On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
>
> Author: luc
> Date:
Le 2012-09-06 13:58, Sébastien Brisard a écrit :
Hi Luc,
2012/9/6 luc :
Hi all,
Le 2012-09-06 07:08, Sébastien Brisard a écrit :
Hi Gilles,
2012/9/6 sebb :
On 5 September 2012 22:46, Gilles Sadowski
wrote:
On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote:
Author: luc
59 matches
Mail list logo
