Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of
 SRS0=ahnF=HJ=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120909222632.GL24856@dusk.harfang.homelinux.org>
References: <20120905183008.B669A23889B8@eris.apache.org>
	<20120905214639.GD24856@dusk.harfang.homelinux.org>
	<CAOGo0VYTmCkxNpt+y59V7kZb3uk-v4YgAVttM_whApUROVdK-w@mail.gmail.com>
	<CAGRH7HpnCyG3oFhkrdFfGY47FZaVjRjVELMTD-T8B7XRQaACfg@mail.gmail.com>
	<ed340d0267f87a8280baeb405da566fb@spaceroots.org>
	<CAGRH7HqRCHhdYFAi_pGXBAQNjsyiveL3AE-231yF6r=YJBOr9A@mail.gmail.com>
	<20120906121618.GS20488@dusk.harfang.homelinux.org>
	<5048A3D5.8030502@gmail.com>
	<20120909113454.GJ24856@dusk.harfang.homelinux.org>
	<504CC0F3.6010200@gmail.com>
	<20120909222632.GL24856@dusk.harfang.homelinux.org>
Date: Mon, 10 Sep 2012 08:11:10 +0200
Message-ID: 
 <CAGRH7HrC-6Oxt5FV52tFcuyaG4oieS9H97M3K+cmtCYjs5KEZw@mail.gmail.com>
Subject: Re: [Math] About "NullArgumentException"
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

2012/9/10 Gilles Sadowski <gilles@harfang.homelinux.org>:
> 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 proposal was that CM never checks for "null" and lets the JVM do i=
t (and
>> > thus throw the standard NPE).
>> >
>> > Phil wants to retain some null checks but opposes to throwing a NPE wi=
thout
>> > a "detailed message".
>> > The localization mechanism being implemented in "ExceptionContext", we
>> > cannot throw a standard NPE (since the error message won't be localize=
d).
>> >
>> > For a consistent behaviour (as seen from the caller), we would have to
>> > implement a subclass of the standard NPE: callers could do
>> >
>> >  try {
>> >    // Call CM
>> >  } catch (NullPointerException e) {
>> >    // Handle NPE (raised by the JVM _or_ by CM).
>> >  }
>> >
>> > However, this breaks the consensus we arrived at (for v4.0) about CM
>> > throwing only subclasses of "MathRuntimeExceprion" (singly rooted hier=
archy).
>> >
>> > Phil proposes to throw MathIAE (IMO, it must be the specific
>> > "NullArgumentException"), but this breaks the above use-case: Users ha=
ve to
>> > do
>> >
>> >  try {
>> >    // Call CM
>> >  } catch (NullPointerException e) {
>> >    // Handle NPE (raised by the JVM).
>> >  } catch (NullArgumentException e)
>> >    // Handle NPE (raised by CM).
>> >  }
>> >
>> > showing blatantly that CM is not consistent: sometimes it lets a JVM
>> > exception propagate, and sometimes it catches the problem eralier and =
throws
>> > an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
>> > "MathRuntimeException").
>> > This is the current state of affairs, and I think that it is not
>> > satisfactory. [As proven by this issue having recurred two or three ti=
mes
>> > already.]
>> >
>> > In light of this, I propose that either
>> > * Phil changes his mind (no check for null performed in CM code), or
>> > * we make an exception to the singly-rooted hierarchy just for
>> >   "NullArgumentException" (which, in 4.0, would become a subclass of t=
he
>> >   standard NPE).
>>
>> Why not just leave things alone [...]
>
> For the reason I gave above: the inconsistent/non-existent policy will ma=
ke
> the issue recur sooner or later, as it happened now with S=E9bastien, as =
it
> happened with me when I first signalled the burden of checked excpetions =
and
> later when we agreed about MathRuntimeException, then changed again, to c=
ome
> back again now, to where we were almost two years ago (IIRC)...
>
>> - i.e., let some APIs document null
>> handling and throw IAE at the point of method invocation when
>> supplying a null violates the documented API contract?
>
> The answer to that question is in the previous post.
>
>> We can leave the (needless, IMO) NullArgumentException as a subclass
>> of MathIAE in place, or drop it and throw MathIAE directly in these
>> cases.
>
> "NullArgumentException" is about as needless as any subclass of "Exceptio=
n"
> or "RuntimeException". Either we use inheritance for what it's primarily
> meant or we choose another, non-OO, language.
>
> This is going in circles; some people will drop from the discussion (or
> already did) and some time from now, someone will "rediscover" this, amon=
g
> other little defects of CM. These are worth correcting, but not worth
> discussing endlessly.
>
> Let's just have all people here provide their preference and be done with
> it.
>
Since there is no way to enforce a strict policy on checking for null
in CM, I think that NAE is useless, and should be droped.
If we assume that every user of CM can use a debugger, then probably
(and contrary to what I advocated earlier), checking early for null is
also superfluous.
I tend to document arguments which *can* be null (I think someone else
also mentioned this practice), so that it's fairly safe (as someone
already wrote) to assume that all other arguments *must* be non-null.

To sum up, I would favor complete removal of NAE. As for existing
checks, I would either remove them, or throw an argumentless standard
NPE.

Phil was talking about loss of robustness. I don't think that CM as a
whole is robust with respect to null pointers. In some places, the
code fails in the standard way (NPE), while in others, it fails in a
fully documented way. Since this is inconsistent, I don't think we
should be afraid of losing robustness in the case of complete removal
of existing checks for null. Again, I'm happy to keep them, but I'd
rather throw a standard NPE in this case.

S=E9bastien

>
> Gilles
>
> P.S. Is there an occurrence in CM, where a method can be passed a null
>      argument?
>
>
>>
>> Phil
>>
>> >
>> > The second option cares for all the various positions _except_ the
>> > singly-rooted hierarchy.
>> >
>> >
>> > Regards,
>> > Gilles
>> >
>> > ---------------------------------------------------------------------
>> > 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