commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Ring <>
Subject Re: [Math] About "NullArgumentException"
Date Mon, 10 Sep 2012 22:43:53 GMT

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
> 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).

I think a standard NPE should be thrown as soon as a null is detected
where one shouldn't be. If the caller passes in a null and the callee
knows that's bad, throw the NPE right there. Fail fast.

> Phil wants to retain some null checks but opposes to throwing a NPE without
> a "detailed message".
> The localization mechanism being implemented in "ExceptionContext", we
> cannot throw a standard NPE (since the error message won't be localized).

I personally think that localizing exceptions is madness. Maybe that's
just me. Why not localize the CM source code as well? L10n is a
problem for application writers and not math libraries.

It seems to me that CM is trying to achieve documentation through
exceptions, as if the exceptions thrown should guide the user how to
use the library. This is the job of javadoc, tutorials, wikis, etc.

> 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).
>  }

Is this going to be the typical case? NPE indicates a programming
error, so this is something that *should* completely crash your JVM.

> However, this breaks the consensus we arrived at (for v4.0) about CM
> throwing only subclasses of "MathRuntimeExceprion" (singly rooted hierarchy).
> Phil proposes to throw MathIAE (IMO, it must be the specific
> "NullArgumentException"), but this breaks the above use-case: Users have 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 times
> already.]

+1 this is terrible from an API design perspective

> 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 the
>   standard NPE).
> The second option cares for all the various positions _except_ the
> singly-rooted hierarchy.
> Regards,
> Gilles

Hope you can all work it out. I would start by dropping the
document-by-exception thinking that seems to permeate these


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message