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

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

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

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

Reply via email to